perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Gifford <sgiff...@suspectclass.com>
Subject Re: first time debugging apache/mod_perl Seg fault
Date Tue, 14 Jul 2009 15:39:39 GMT
Alan McKay <alan.mckay@gmail.com> writes:

> Here is what I am doing based on the mod-perl debugging page I
> referred to in my first email.   I basically load the core dump in
> gdb, and then alternately do "up" and "curinfo" on each line shown.
> Sometimes I end up with what I got here where I get to a certain point
> and it says "cannot access memory at ...", and sometimes I can get
> through the whole back trace in the "up/curinfo" manner without that.
> But never does it tell me it found a my_perl
>
> Not sure why sometimes I get that error and sometimes not.  To the
> best of my knowledge I'm doing the same thing every time.
>
>>  end
> (gdb) bt
> #0  0x0044e172 in Perl_cv_const_sv () from
> /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
> #1  0x00442a7c in Perl_yylex () from

It looks like maybe it's dying in the parser...

> /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
> #2  0x0044b295 in Perl_yyparse () from
> /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
> #3  0x004b8200 in Perl_pp_range () from
> /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
> #4  0x004ba0b2 in Perl_pp_require () from

...while parsing an external file.  Maybe sticking some debugging
information around your require/use/do statements (inside of BEGIN
blocks) would help you narrow down what file it is.

I have had to debug these things before, and they're very painful!  I
usually end up commenting out half the code at a time to narrow things
down, and it's never what I expect.  Usually it's a module with a
compiled library, i.e. not a pure-Perl module.

Good luck!

----Scott.

Mime
View raw message