Re: seg fault in modperl_perl_global_request_save

On Thu, 31 Dec 2009, Philippe M. Chiasson wrote:

> On 09-12-31 12:52 , Alex Aminoff wrote:
>>
>>> Most certainly, yes.  A stack trace without debugging symbols is not
>>> very useful in trying to pin down the source of a segfault bug.
>>
>> OK, I compiled mod_perl with MP_DEBUG and MP_TRACE, and
>> got apache to produce a core dump (kern.sugid_coredump=1 appears to be
>> needed on FreeBSD):
>>
>> (gdb) bt
>> #0  0x28384eb4 in strncpy () from /lib/libc.so.7
>
>
>> #1  0x287af9ee in modperl_perl_global_avcv_clear ()
>>    from /usr/local/libexec/apache22/mod_perl.so
>> #2  0x287afacf in modperl_perl_global_avcv_clear ()
>>    from /usr/local/libexec/apache22/mod_perl.so
>
>
> That's odd, modperl_perl_global_avcv_clear should not be able to call
> itself. It looks like you don't have debugging symbols for mod_perl
> itself, could you get that as well, as it would show me a little bit
> more as to what's being double-freed, looks like.
>
> Also, you can just try and run your test case with MOD_PERL_TRACE='g' in
> your environment ? It turns on global handling debugging output.
> error_log would contain information about what is going on in more details.

Well, we think we fixed our problem. I believe this is the same bug as 
discussed in

  http://www.gossamer-threads.com/lists/modperl/modperl/100066

we found a couple places where $/ was being assigned-to globally, fixed 
those with local, and now no more seg faults. Thanks for your help!

   - Alex Aminoff
     BaseSpace.net
     National Bureau of Economic Research (nber.org)