You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Mike Taylor <mi...@miketaylor.org.uk> on 2005/04/26 16:39:08 UTC
[mp1] segmentation fault in Apache->server->dir_config()
I wonder if anyone has any light to shed on this peculiar problem?
Last night I rebooted a server that's been running happily for several
months, changing nothing. When it came up, all my HTML::Mason-based
sites no longer worked, with all requests routed through Mason causing
the child server to seggy-fault with no information in the logs.
Through careful detective work, I traced the problem to an invocation
of $s->dir_config(), where $s is the result of Apache->server().
Although I first ran into this in the context of HTML::Mason, much
simpler test programs also show the same problem:
#!/usr/bin/perl -w
use strict;
use CGI;
my $cgi = new CGI();
print $cgi->header(-type => "text/plain");
my $which = $cgi->param("which");
if (!defined $which) {
print "Test what?";
} else {
warn "test.pl: checking\n";
my $request = Apache->request();
warn "test.pl: request='$request'\n";
my $server = Apache->server();
warn "test.pl: server='$server'\n";
my $config = $server->dir_config();
warn "test.pl: config='$config'\n";
my $val = $config->get($which);
warn "test.pl: val='$val'\n";
print $val;
}
This gets as far as writing the following lines to the site error-log:
test.pl: checking
test.pl: request='Apache=SCALAR(0x82203bc)'
test.pl: server='Apache::Server=SCALAR(0x83602cc)'
then quits before writing the "config=" line. At this point, a single
line is written to the master error-log.
[Tue Apr 26 15:32:10 2005] [notice] child pid 8777 exit signal Segmentation fault (11)
The bizarre thing is that, as I said, _nothing_ has changed since
yesterday, when this worked just fine.
I tried to run httpd under both strace and gdb, but I have not managed
to get any useful information out of it that way. I am using Apache
1.3.33 with mod_perl 1.29 (the most recent 1.x versions of both, I
believe) both built from source.
Here is the relevant section of my httpd.conf:
<VirtualHost localhost.localnet>
ServerName sru.miketaylor.org.uk
DocumentRoot /usr/local/src/mike/sru/htdocs
ErrorLog /usr/local/src/mike/sru/logs/error.log
CustomLog /usr/local/src/mike/sru/logs/access.log combined
<FilesMatch "\.pl$">
Options +ExecCGI
SetHandler perl-script
PerlHandler Apache::Registry
</FilesMatch>
</VirtualHost>
Pretty vanilla, I think you'll agree.
All suggestions welcome! Thanks.
_/|_ ___________________________________________________________________
/o ) \/ Mike Taylor <mi...@miketaylor.org.uk> http://www.miketaylor.org.uk
)_v__/\ "Everything free in America, for a small fee in America" --
Steven Sondheim, "West Side Story"
--
Listen to free demos of soundtrack music for film, TV and radio
http://www.pipedreaming.org.uk/soundtrack/
Re: [mp1] segmentation fault in Apache->server->dir_config()
Posted by Mike Taylor <mi...@miketaylor.org.uk>.
> Date: Tue, 26 Apr 2005 22:05:08 -0400
> From: Stas Bekman <st...@stason.org>
>
> hmm, I guess there still some people using mp1. This is so
> unfashionable. Everybody wears RC5 these days :)
:-)
I did initially try to use mod_perl2 and Apache2, but I couldn't get
the HTML::Mason module to work with them; and since Mason is my reason
for wanting to use mod_perl at all, I backed down to 1.x.
>> The bizarre thing is that, as I said, _nothing_ has changed since
>> yesterday, when this worked just fine.
>
> Mike, have you by chance upgraded some modules between the last
> server startup and reboot? Remember that mod_perl won't see any
> changes until restarted, so if you did change things you could have
> known whether they have affected mod_perl or not.
I wish it were so! But, no; that machine's Apache server has been
reloaded and restarted half a dozen times every day, as I've tweaked
its configuration. I am quite certain that I didn't make an
configuration changes that didn't immediately get tested. So, no,
nothing explicitly changed between the last restart of Apache before
the reboot, and the reboot itself. Which makes me think it must be
something that was in the running state of the computer -- but what?
I really can't imagine.
>> I tried to run httpd under both strace and gdb, but I have not
>> managed to get any useful information out of it that way. I am
>> using Apache 1.3.33 with mod_perl 1.29 (the most recent 1.x
>> versions of both, I believe) both built from source.
>
> Mike, you need to get the core backtrace. Please check:
> 'Getting the Backtrace From Core Dumps' at
> http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems
> for details. Also an output of 'perl -V' would be helpful.
Backtrace to follow. In the mean time, here is the perl -V output.
Thanks for your help.
--
$ perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.21-1.1931.2.382.entsmp, archname=i386-linux-thread-multi
uname='linux stripples.devel.redhat.com 2.4.21-1.1931.2.382.entsmp #1 smp wed aug 6 17:18:52 edt 2003 i686 i686 i386 gnulinux '
config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -g -pipe -march=i386 -mcpu=i686',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='3.2.2 20030222 (Red Hat Linux 3.2.2-5)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil
libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Locally applied patches:
MAINT18379
Built under linux
Compiled at Aug 13 2003 11:47:58
@INC:
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
.
$
_/|_ ___________________________________________________________________
/o ) \/ Mike Taylor <mi...@miketaylor.org.uk> http://www.miketaylor.org.uk
)_v__/\ "I want to create an omelet that expresses the meaninglessness
of existence, and instead they taste like cheese" -- Marty Smith,
"The Jean-Paul Sartre Cookbook"
--
Listen to free demos of soundtrack music for film, TV and radio
http://www.pipedreaming.org.uk/soundtrack/
Re: [mp1] segmentation fault in Apache->server->dir_config()
Posted by Stas Bekman <st...@stason.org>.
Mike Taylor wrote:
> I wonder if anyone has any light to shed on this peculiar problem?
hmm, I guess there still some people using mp1. This is so unfashionable.
Everybody wears RC5 these days :)
> Last night I rebooted a server that's been running happily for several
> months, changing nothing. When it came up, all my HTML::Mason-based
> sites no longer worked, with all requests routed through Mason causing
> the child server to seggy-fault with no information in the logs.
[...]
> The bizarre thing is that, as I said, _nothing_ has changed since
> yesterday, when this worked just fine.
Mike, have you by chance upgraded some modules between the last server
startup and reboot? Remember that mod_perl won't see any changes until
restarted, so if you did change things you could have known whether they
have affected mod_perl or not.
> I tried to run httpd under both strace and gdb, but I have not managed
> to get any useful information out of it that way. I am using Apache
> 1.3.33 with mod_perl 1.29 (the most recent 1.x versions of both, I
> believe) both built from source.
Mike, you need to get the core backtrace. Please check:
'Getting the Backtrace From Core Dumps' at
http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems
for details. Also an output of 'perl -V' would be helpful.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com