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