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)
>> 
>>   
>