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)
