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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
