Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of sog@msg.com.mx designates
 200.33.54.1 as permitted sender)
Message-ID: <4CCBA22B.2070501@msg.com.mx>
Date: Fri, 29 Oct 2010 23:42:19 -0500
From: Salvador Ortiz Garcia <sog@msg.com.mx>
Organization: =?ISO-8859-1?Q?Mat=EDas_Software_Group?=
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7
MIME-Version: 1.0
To: Brian Hirt <bhirt@me.com>
CC: modperl@perl.apache.org
Subject: Re: mod_perl 1.30 seg faults
References: <28E714B4-1421-4CCF-8A01-A97BDE8CE922@me.com>
In-Reply-To: <28E714B4-1421-4CCF-8A01-A97BDE8CE922@me.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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