RE: Apache 1.3.14 and Apache::RegistryLoader
I thought I'd let the list know that I resolved the problem,
even though the lack of response leads me to believe that it
is a problem that only I am experiencing.
It turns out that the installation of Solaris that I was
on lacked the patch 106950-13, which among other things
addressed problems with dynamic linking. My installation
was only at 106950-06. When I tried it on another box
that was at 106950-11, it worked fine. Now to pack the
original box!
-Paul
-Original Message-
From: Paul G. Weiss
Sent: Wednesday, November 01, 2000 2:50 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Apache 1.3.14 and Apache::RegistryLoader
More info on the problem for some kind soul:
When I run the server under gdb in single server
mode it produces the following output:
[New LWP2]
[New LWP3]
Program received signal SIGSEGV, Segmentation fault.
0xff3b9c64 in ?? ()
(gdb) i thread
6 Thread 3 0xfe3ce64c in _reap_wait () from
/usr/lib/libthread.so.1
5 Thread 2 (LWP 2) 0xff2174bc in _signotifywait () from
/usr/lib/libc.so.1
* 4 Thread 1 (LWP 1) 0xff3b9c64 in ?? ()
3 LWP3 0xff215094 in door_restart () from
/usr/lib/libc.so.1
2 LWP2 0xff2174bc in _signotifywait () from
/usr/lib/libc.so.1
1 LWP1 0xff3b9c64 in ?? ()
(gdb) bt
#0 0xff3b9c64 in ?? ()
#1 0xff3be3a8 in ?? ()
#2 0xff3bd4a0 in ?? ()
#3 0xff3bd4fc in ?? ()
#4 0x4bed4 in ap_os_dso_unload (handle=0xfeed19a4) at os.c:133
#5 0xfedc1864 in unload_xs_so (librefs=0xb18d0) at mod_perl.c:480
#6 0xfedc18a4 in mp_dso_unload (data=0x7cb90) at mod_perl.c:512
#7 0x1c2c8 in run_cleanups (c=0x92738) at alloc.c:1946
#8 0x19a04 in ap_clear_pool (a=0x7cb90) at alloc.c:689
#9 0x3298c in standalone_main (argc=6, argv=0xffbefac4) at
http_main.c:4741
#10 0x337a4 in main (argc=6, argv=0xffbefac4) at http_main.c:5123
(gdb) frame 4
#4 0x4bed4 in ap_os_dso_unload (handle=0xfeed19a4) at os.c:133
(gdb)
The last frame for which I have symbols shows the following:
void ap_os_dso_unload(void *handle)
{
#if defined(HPUX) || defined(HPUX10) || defined(HPUX11)
shl_unload((shl_t)handle);
#elif defined(HAVE_DYLD)
NSUnLinkModule(handle,FALSE);
#else
= dlclose(handle);
#endif
return;
}
Again, can I ask if anyone out there is doing the following:
using 1.3.14 under Solaris 2.7
using DSO's
using Perl 5.6.0 built w/o threading options
Is this a no-no?
By the way, I have simplified my startup script to only
make a single call to Apache::RegistryLoader::handler
for a particular file. Same result. Without the call
to Apache::RegistryLoader::handler the server seems to
perform flawlessly.
-Paul
-Original Message-
From: Paul G. Weiss
Sent: Tuesday, October 31, 2000 3:37 PM
To: '[EMAIL PROTECTED]'
Subject: Apache 1.3.14 and Apache::RegistryLoader
I tried using Apache::RegistryLoader with my
Apache 1.3.14/mod_perl 1.24_2 installation.
I put this in a file that I PerlRequire:
use Apache::RegistryLoader ();
my $perl_dir = Apache-server_root_relative."docs";
my $cmd = qq{find $perl_dir -follow \\( -name "*.pl" -o -name
"*.cgi" \\) -print};
my $output = `$cmd`;
my @files = split /\s+/, $output;
my $rl = Apache::RegistryLoader-new;
foreach my $file (@files)
{
print "pre-loading $file\n";
$file =~ /$perl_dir(.*)/;
my $status = $rl-handler($1, $file);
unless($status == 200) {
warn "pre-load of `$url' failed, status=$status\n";
}
}
(In other words, I load every .cgi or .pl file found under a certain
directory. I've also coded it with File::Find instead of running
find as a separate process with the same results.)
The results were not good. This appeared in error_log:
[Tue Oct 31 15:26:32 2000] [notice] caught SIGTERM, shutting down
signal fault in critical section
signal number: 11, signal code: 1, fault address: 0x1a5c,
pc: 0xff3b9c64, sp: 0xffbef530
libthread panic: fault in libthread critical section (PID:
19927 LWP 1)
stacktrace:
ff3b9c30
ff3be3a0
ff3bd498
ff3bd4f4
4bfd8
fedc185c
fedc189c
1c2c4
199fc
329f0
33808
18e98
0
This is under Solaris 2.7. The perl that I used for mod_perl was not
built with any threading options. Is this now required, given that
Apache 1.3.14 appears to be using threads?
-Paul
RE: Apache 1.3.14 and Apache::RegistryLoader
Hi Paul, On Tue, 7 Nov 2000, Paul G. Weiss wrote: I thought I'd let the list know that I resolved the problem, even though the lack of response leads me to believe that it is a problem that only I am experiencing. It turns out that the installation of Solaris that I was on lacked the patch 106950-13, which among other things addressed problems with dynamic linking. My installation was only at 106950-06. When I tried it on another box that was at 106950-11, it worked fine. Now to pack the original box! Thanks for sharing that with the List, Paul. 73, Ged.
RE: Apache 1.3.14 and Apache::RegistryLoader
More info on the problem for some kind soul:
When I run the server under gdb in single server
mode it produces the following output:
[New LWP2]
[New LWP3]
Program received signal SIGSEGV, Segmentation fault.
0xff3b9c64 in ?? ()
(gdb) i thread
6 Thread 3 0xfe3ce64c in _reap_wait () from
/usr/lib/libthread.so.1
5 Thread 2 (LWP 2) 0xff2174bc in _signotifywait () from
/usr/lib/libc.so.1
* 4 Thread 1 (LWP 1) 0xff3b9c64 in ?? ()
3 LWP3 0xff215094 in door_restart () from /usr/lib/libc.so.1
2 LWP2 0xff2174bc in _signotifywait () from
/usr/lib/libc.so.1
1 LWP1 0xff3b9c64 in ?? ()
(gdb) bt
#0 0xff3b9c64 in ?? ()
#1 0xff3be3a8 in ?? ()
#2 0xff3bd4a0 in ?? ()
#3 0xff3bd4fc in ?? ()
#4 0x4bed4 in ap_os_dso_unload (handle=0xfeed19a4) at os.c:133
#5 0xfedc1864 in unload_xs_so (librefs=0xb18d0) at mod_perl.c:480
#6 0xfedc18a4 in mp_dso_unload (data=0x7cb90) at mod_perl.c:512
#7 0x1c2c8 in run_cleanups (c=0x92738) at alloc.c:1946
#8 0x19a04 in ap_clear_pool (a=0x7cb90) at alloc.c:689
#9 0x3298c in standalone_main (argc=6, argv=0xffbefac4) at http_main.c:4741
#10 0x337a4 in main (argc=6, argv=0xffbefac4) at http_main.c:5123
(gdb) frame 4
#4 0x4bed4 in ap_os_dso_unload (handle=0xfeed19a4) at os.c:133
(gdb)
The last frame for which I have symbols shows the following:
void ap_os_dso_unload(void *handle)
{
#if defined(HPUX) || defined(HPUX10) || defined(HPUX11)
shl_unload((shl_t)handle);
#elif defined(HAVE_DYLD)
NSUnLinkModule(handle,FALSE);
#else
= dlclose(handle);
#endif
return;
}
Again, can I ask if anyone out there is doing the following:
using 1.3.14 under Solaris 2.7
using DSO's
using Perl 5.6.0 built w/o threading options
Is this a no-no?
By the way, I have simplified my startup script to only
make a single call to Apache::RegistryLoader::handler
for a particular file. Same result. Without the call
to Apache::RegistryLoader::handler the server seems to
perform flawlessly.
-Paul
-Original Message-
From: Paul G. Weiss
Sent: Tuesday, October 31, 2000 3:37 PM
To: '[EMAIL PROTECTED]'
Subject: Apache 1.3.14 and Apache::RegistryLoader
I tried using Apache::RegistryLoader with my
Apache 1.3.14/mod_perl 1.24_2 installation.
I put this in a file that I PerlRequire:
use Apache::RegistryLoader ();
my $perl_dir = Apache-server_root_relative."docs";
my $cmd = qq{find $perl_dir -follow \\( -name "*.pl" -o -name "*.cgi" \\)
-print};
my $output = `$cmd`;
my @files = split /\s+/, $output;
my $rl = Apache::RegistryLoader-new;
foreach my $file (@files)
{
print "pre-loading $file\n";
$file =~ /$perl_dir(.*)/;
my $status = $rl-handler($1, $file);
unless($status == 200) {
warn "pre-load of `$url' failed, status=$status\n";
}
}
(In other words, I load every .cgi or .pl file found under a certain
directory. I've also coded it with File::Find instead of running
find as a separate process with the same results.)
The results were not good. This appeared in error_log:
[Tue Oct 31 15:26:32 2000] [notice] caught SIGTERM, shutting down
signal fault in critical section
signal number: 11, signal code: 1, fault address: 0x1a5c,
pc: 0xff3b9c64, sp: 0xffbef530
libthread panic: fault in libthread critical section (PID: 19927 LWP 1)
stacktrace:
ff3b9c30
ff3be3a0
ff3bd498
ff3bd4f4
4bfd8
fedc185c
fedc189c
1c2c4
199fc
329f0
33808
18e98
0
This is under Solaris 2.7. The perl that I used for mod_perl was not
built with any threading options. Is this now required, given that
Apache 1.3.14 appears to be using threads?
-Paul
RE: Apache 1.3.14 and Apache::RegistryLoader
I have no idea, but if it helps, here is a snip from my startup.pl
it works just fine on:
1.3.14/perl5.6 (-Dusethreads)/linux(RH6.2)/modperl cvs (1.24_02)
1.3.14/perl5.00503/Solaris/modperl 1.24_01
my $rl = Apache::RegistryLoader-new;
my $dh = DirHandle-new("/usr/local/apache/perl-bin") || die $!;
foreach my $file ($dh-read) {
next unless $file =~ m/\.pl$|\.cgi$/;
print "pre-loading $file\n";
$rl-handler("/perl-bin/$file" = "/usr/local/apache/perl-bin/$file");
}
although hardcoded, I've never had a problem with it and it...
HTH
--Geoff
-Original Message-
From: Paul G. Weiss [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 31, 2000 3:37 PM
To: '[EMAIL PROTECTED]'
Subject: Apache 1.3.14 and Apache::RegistryLoader
I tried using Apache::RegistryLoader with my
Apache 1.3.14/mod_perl 1.24_2 installation.
I put this in a file that I PerlRequire:
use Apache::RegistryLoader ();
my $perl_dir = Apache-server_root_relative."docs";
my $cmd = qq{find $perl_dir -follow \\( -name "*.pl" -o -name
"*.cgi" \\)
-print};
my $output = `$cmd`;
my @files = split /\s+/, $output;
my $rl = Apache::RegistryLoader-new;
foreach my $file (@files)
{
print "pre-loading $file\n";
$file =~ /$perl_dir(.*)/;
my $status = $rl-handler($1, $file);
unless($status == 200) {
warn "pre-load of `$url' failed, status=$status\n";
}
}
(In other words, I load every .cgi or .pl file found under a certain
directory. I've also coded it with File::Find instead of running
find as a separate process with the same results.)
The results were not good. This appeared in error_log:
[Tue Oct 31 15:26:32 2000] [notice] caught SIGTERM, shutting down
signal fault in critical section
signal number: 11, signal code: 1, fault address: 0x1a5c,
pc: 0xff3b9c64, sp: 0xffbef530
libthread panic: fault in libthread critical section (PID:
19927 LWP 1)
stacktrace:
ff3b9c30
ff3be3a0
ff3bd498
ff3bd4f4
4bfd8
fedc185c
fedc189c
1c2c4
199fc
329f0
33808
18e98
0
This is under Solaris 2.7. The perl that I used for mod_perl was not
built with any threading options. Is this now required, given that
Apache 1.3.14 appears to be using threads?
-Paul
