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<signal handler called>
>> #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)
>>
>>
>
|