You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Philippe M. Chiasson" <go...@ectoplasm.org> on 2009/04/08 04:17:27 UTC
Re: mod_perl crashes with Perl 5.10
On 29/3/09 15:30, Jozef Kosoru wrote:
> Hello,
>
> I tested my mod_perl application using following combinations recently:
>
> * Apache/2.2.9 (Debian) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0
> (default Debian Lenny packages, mpm-prefork)
>
> * Apache/2.2.11 (Unix) mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.0
> (apache, apreq and mod_perl compiled from sources, mpm-prefork)
>
> and I see a crash of Apache process on each request.
Just to be sure, is that a 32/64 bit platform ?
> Here's the backtrace:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb7ce0ad0 (LWP 11196)]
> 0xb7bf2095 in Perl_pp_undef () from /usr/lib/libperl.so.5.10
> (gdb) bt
> #0 0xb7bf2095 in Perl_pp_undef () from /usr/lib/libperl.so.5.10
> #1 0xb7bc2dc1 in Perl_runops_standard () from /usr/lib/libperl.so.5.10
> #2 0xb7bbcd38 in Perl_call_sv () from /usr/lib/libperl.so.5.10
> #3 0xb7cb2bfc in modperl_callback (my_perl=0x9ab21a0, handler=0x9639b18, p=0x9ad4578,
> r=0x9ad45b8, s=0x961bfe0, args=0x98a13c0) at modperl_callback.c:101
Hrm, if at all possible, while in gdb, could you dump more information from that frame ?
(gdb) info locals
Also, I'd love to see as much of the arguments as possible, expecially handler, r and args
(gdb) print *handler
(gdb) print *r
(gdb) print *args
Thanks.
Also, one thing that always help narrow things down is if you could boil down your application
to a small enough test case that you could share it with us.
--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/
Re: mod_perl crashes with Perl 5.10
Posted by Jozef Kosoru <zy...@uid0.sk>.
Hi Philippe,
(Sorry for the delay with my answer - I'll be quick from now on)
Thank you for your interest to help me with this crasher.
On Tue, Apr 07, 2009 at 22:17:27 -0400, Philippe M. Chiasson wrote:
> On 29/3/09 15:30, Jozef Kosoru wrote:
> > Hello,
> >
> > I tested my mod_perl application using following combinations recently:
> >
> > * Apache/2.2.9 (Debian) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0
> > (default Debian Lenny packages, mpm-prefork)
> >
> > * Apache/2.2.11 (Unix) mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.0
> > (apache, apreq and mod_perl compiled from sources, mpm-prefork)
> >
> > and I see a crash of Apache process on each request.
>
> Just to be sure, is that a 32/64 bit platform ?
This is 32 bit. I can check on 64 bit.
> > Here's the backtrace:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0xb7ce0ad0 (LWP 11196)]
> > 0xb7bf2095 in Perl_pp_undef () from /usr/lib/libperl.so.5.10
> > (gdb) bt
> > #0 0xb7bf2095 in Perl_pp_undef () from /usr/lib/libperl.so.5.10
> > #1 0xb7bc2dc1 in Perl_runops_standard () from /usr/lib/libperl.so.5.10
> > #2 0xb7bbcd38 in Perl_call_sv () from /usr/lib/libperl.so.5.10
> > #3 0xb7cb2bfc in modperl_callback (my_perl=0x9ab21a0, handler=0x9639b18, p=0x9ad4578,
> > r=0x9ad45b8, s=0x961bfe0, args=0x98a13c0) at modperl_callback.c:101
>
> Hrm, if at all possible, while in gdb, could you dump more information from that frame ?
>
> (gdb) info locals
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7cf9ad0 (LWP 8233)]
0xb7c0b095 in Perl_pp_undef () from /usr/lib/libperl.so.5.10
(gdb) info locals
No symbol table info available.
Any clue?
> Also, I'd love to see as much of the arguments as possible, expecially handler, r and args
>
> (gdb) print *handler
> (gdb) print *r
> (gdb) print *args
Same with others:
(gdb) print *handler
No symbol "handler" in current context.
(gdb) print *r
No symbol "r" in current context
(gdb) print *args
No symbol "args" in current context
Do I have to recompile Perl with some special debug symbols?
> Thanks.
>
> Also, one thing that always help narrow things down is if you could
> boil down your application to a small enough test case that you could
> share it with us.
I was trying to do so but haven't succeded with any minimalized
test-case yet. But it's not really so much code anyway and it's all GPL.
I'll try to make an easy package of it.
Regards,
Jozef
--
Jozef Kosoru
http://zyzstar.kosoru.com