mod_perl 1.30 seg faults

I'm running a modperl installation with 1.30 and apache 1.3.42.

I recently upgrade from Ubuntu 9.04 to Ubuntu 10.04 and now every time a mod perl process shuts, it dumps core. None of the application code changed. Maybe modperl isn't playing nicely with perl 5.10.1 (the old machine had 5.10.0)? Luckily it's not causing a problem since the core dump doesn't happen during a regular request. However it was fun watching the machine try to write 20gb of core dumps every few minutes....

Does anyone have any idea why this is happening or what I can do? I know 1.30 is old and apache 1.3.42 is end of life. Yes we will be upgrading to a newer version in the future, but I'm trying to find an interim solution over the next few months.

Any help is much appreciated.

Thanks!
Brian

Program terminated with signal 11, Segmentation fault.
#0 0x4012ad6a in Perl_av_undef () from /usr/lib/libperl.so.5.10
(gdb) bt
#0 0x4012ad6a in Perl_av_undef () from /usr/lib/libperl.so.5.10
#1 0x080842b0 in perl_shutdown (s=0xa09705c, p=0xd839a44) at mod_perl.c:284
#2 0x0808470a in perl_child_exit_cleanup (data=0xd839bd4) at mod_perl.c:940
#3 0x080c47dd in run_cleanups (c=0xd839bdc) at alloc.c:1703
#4 0x080c31e6 in ap_clear_pool (a=0xd839a44) at alloc.c:499
#5 0x080c325a in ap_destroy_pool (a=0xd839a44) at alloc.c:529
#6 0x080d12cd in clean_child_exit (code=0) at http_main.c:543
#7 0x080d340d in just_die (sig=15) at http_main.c:3258
#8
#9 0x4001d422 in __kernel_vsyscall ()
#10 0x402c68ab in semop () from /lib/tls/i686/cmov/libc.so.6
#11 0x080d14f7 in accept_mutex_on_sysvsem () at http_main.c:895
#12 0x080d4ac7 in child_main (child_num_arg=0) at http_main.c:4589
#13 0x080d51d4 in make_child (s=0xa09705c, slot=0, now=1287622896) at http_main.c:5055
#14 0x080d526a in startup_children (number_to_start=5) at http_main.c:5083
#15 0x080d5a54 in standalone_main (argc=1, argv=0xbf8ab984) at http_main.c:5430
#16 0x080d632a in main (argc=1, argv=0xbf8ab984) at http_main.c:5773
(gdb)

Re: mod_perl 1.30 seg faults

Hi Brian,

That bug was fixed in mod_perl 1.31.

Sure you can upgrade to last 1.x mod_perl.

Regards.

Salvador Ortiz.

On 10/29/2010 02:50 PM, Brian Hirt wrote:
> I'm running a modperl installation with 1.30 and apache 1.3.42.
>
> I recently upgrade from Ubuntu 9.04 to Ubuntu 10.04 and now every time a mod perl process shuts, it dumps core. None of the application code changed. Maybe modperl isn't playing nicely with perl 5.10.1 (the old machine had 5.10.0)? Luckily it's not causing a problem since the core dump doesn't happen during a regular request. However it was fun watching the machine try to write 20gb of core dumps every few minutes....
>
> Does anyone have any idea why this is happening or what I can do? I know 1.30 is old and apache 1.3.42 is end of life. Yes we will be upgrading to a newer version in the future, but I'm trying to find an interim solution over the next few months.
>
> Any help is much appreciated.
>
> Thanks!
> Brian
>
> Program terminated with signal 11, Segmentation fault.
> #0 0x4012ad6a in Perl_av_undef () from /usr/lib/libperl.so.5.10
> (gdb) bt
> #0 0x4012ad6a in Perl_av_undef () from /usr/lib/libperl.so.5.10
> #1 0x080842b0 in perl_shutdown (s=0xa09705c, p=0xd839a44) at mod_perl.c:284
> #2 0x0808470a in perl_child_exit_cleanup (data=0xd839bd4) at mod_perl.c:940
> #3 0x080c47dd in run_cleanups (c=0xd839bdc) at alloc.c:1703
> #4 0x080c31e6 in ap_clear_pool (a=0xd839a44) at alloc.c:499
> #5 0x080c325a in ap_destroy_pool (a=0xd839a44) at alloc.c:529
> #6 0x080d12cd in clean_child_exit (code=0) at http_main.c:543
> #7 0x080d340d in just_die (sig=15) at http_main.c:3258
> #8
> #9 0x4001d422 in __kernel_vsyscall ()
> #10 0x402c68ab in semop () from /lib/tls/i686/cmov/libc.so.6
> #11 0x080d14f7 in accept_mutex_on_sysvsem () at http_main.c:895
> #12 0x080d4ac7 in child_main (child_num_arg=0) at http_main.c:4589
> #13 0x080d51d4 in make_child (s=0xa09705c, slot=0, now=1287622896) at http_main.c:5055
> #14 0x080d526a in startup_children (number_to_start=5) at http_main.c:5083
> #15 0x080d5a54 in standalone_main (argc=1, argv=0xbf8ab984) at http_main.c:5430
> #16 0x080d632a in main (argc=1, argv=0xbf8ab984) at http_main.c:5773
> (gdb)
>
>

Re: mod_perl 1.30 seg faults

Thanks,

I don't know how I missed that. I swear I checked that i was running the latest version, /facepalm

--brian


On Oct 29, 2010, at 10:42 PM, Salvador Ortiz Garcia wrote:

> Hi Brian,
>
> That bug was fixed in mod_perl 1.31.
>
> Sure you can upgrade to last 1.x mod_perl.
>
> Regards.
>
> Salvador Ortiz.
>
> On 10/29/2010 02:50 PM, Brian Hirt wrote:
>> I'm running a modperl installation with 1.30 and apache 1.3.42.
>>
>> I recently upgrade from Ubuntu 9.04 to Ubuntu 10.04 and now every time a mod perl process shuts, it dumps core. None of the application code changed. Maybe modperl isn't playing nicely with perl 5.10.1 (the old machine had 5.10.0)? Luckily it's not causing a problem since the core dump doesn't happen during a regular request. However it was fun watching the machine try to write 20gb of core dumps every few minutes....
>>
>> Does anyone have any idea why this is happening or what I can do? I know 1.30 is old and apache 1.3.42 is end of life. Yes we will be upgrading to a newer version in the future, but I'm trying to find an interim solution over the next few months.
>>
>> Any help is much appreciated.
>>
>> Thanks!
>> Brian
>>
>> Program terminated with signal 11, Segmentation fault.
>> #0 0x4012ad6a in Perl_av_undef () from /usr/lib/libperl.so.5.10
>> (gdb) bt
>> #0 0x4012ad6a in Perl_av_undef () from /usr/lib/libperl.so.5.10
>> #1 0x080842b0 in perl_shutdown (s=0xa09705c, p=0xd839a44) at mod_perl.c:284
>> #2 0x0808470a in perl_child_exit_cleanup (data=0xd839bd4) at mod_perl.c:940
>> #3 0x080c47dd in run_cleanups (c=0xd839bdc) at alloc.c:1703
>> #4 0x080c31e6 in ap_clear_pool (a=0xd839a44) at alloc.c:499
>> #5 0x080c325a in ap_destroy_pool (a=0xd839a44) at alloc.c:529
>> #6 0x080d12cd in clean_child_exit (code=0) at http_main.c:543
>> #7 0x080d340d in just_die (sig=15) at http_main.c:3258
>> #8
>> #9 0x4001d422 in __kernel_vsyscall ()
>> #10 0x402c68ab in semop () from /lib/tls/i686/cmov/libc.so.6
>> #11 0x080d14f7 in accept_mutex_on_sysvsem () at http_main.c:895
>> #12 0x080d4ac7 in child_main (child_num_arg=0) at http_main.c:4589
>> #13 0x080d51d4 in make_child (s=0xa09705c, slot=0, now=1287622896) at http_main.c:5055
>> #14 0x080d526a in startup_children (number_to_start=5) at http_main.c:5083
>> #15 0x080d5a54 in standalone_main (argc=1, argv=0xbf8ab984) at http_main.c:5430
>> #16 0x080d632a in main (argc=1, argv=0xbf8ab984) at http_main.c:5773
>> (gdb)
>>
>>
>