it's kind of a grey area as to where this problem is living - hence
the double post. taking a mod_perl module that uses SVN::Core (e.g.
SVN::Web), and either preloading it via PerlLoadModule/PerlModule,
or the + notation in PerlResponseHandler will cause apache to
segfault somewhere around modperl_perl_call_endav (the perl END
block handler). SVN::Core's END block contains apr_terminate().
it seems some sort of desynch is occurring in the teardown after
the initial preflight apache configuration phase. i suspect that
by the time SVN::Core's END block is executed, the pool has already
been freed by mod_perl. my understanding of these inner workings
is fairly limited though.
the platform is osx 10.3.6, apache 2.1.0-dev (worker.c), perl 5.8.5,
mod_perl 1.99_18, apr and apr-util 1.0.1, and subversion 1.1.1.
here's the backtrace. strangely, modperl_perl_call_endav is missing
from the stack, but it shows up if you set the breakpoint to it.
Breakpoint 1, 0x00610758 in modperl_perl_call_list ()
(gdb) bt
#0 0x00610758 in modperl_perl_call_list ()
Reading memory from the sp at: bffffb00
Reading memory from the sp at: bffffb00
Reading memory from the sp at: bffffb00
#1 0x00619998 in modperl_perl_destruct ()
#2 0x006083f0 in modperl_interp_destroy ()
#3 0x006095f0 in modperl_tipool_destroy ()
#4 0x00608548 in modperl_interp_pool_destroy ()
#5 0x003a5f74 in run_cleanups (cref=0x18bc828) at memory/unix/apr_pools.c:1973
#6 0x003a5678 in apr_pool_destroy (pool=0x18bc818) at memory/unix/apr_pools.c:714
#7 0x003a55c0 in apr_pool_clear (pool=0x1806218) at memory/unix/apr_pools.c:673
#8 0x0002870c in main (argc=3, argv=0xbffffe88) at main.c:653
cheers
.dorian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 22 20:59:58 2004