On Mar 8, 2006, at 12:34 PM, Ron Ohmer wrote:
Additional info (Without inadvertent Send Clicks early):
This is the exception being caught in gdb and the backtrace of the
stack
at that point
Program received signal SIGABRT, Aborted.
0xd0126af0 in pthread_kill () from /usr/lib/libpthread.a(shr_xpg5.o)
(gdb) bt
#0 0xd0126af0 in pthread_kill () from /usr/lib/libpthread.a
(shr_xpg5.o)
#1 0xd01265b0 in _p_raise () from /usr/lib/libpthread.a(shr_xpg5.o)
#2 0xd03395ac in raise () from /usr/lib/libc.a(shr.o)
#3 0xd0367458 in abort () from /usr/lib/libc.a(shr.o)
#4 0xd17b3a70 in apr_atomic_dec32 (mem=0x2000ef6c) at
/mcoa300/shared/jfs2/src/RMI/Public/libs/log4cxx-0.9.8/lib/
apr-1.2.2/ato
mic/unix/apr_atomic.c:297
#5 0xd17acf40 in log4cxx::helpers: bjectImpl::releaseRef
(this=0x2000ef68) at
/mcoa300/shared/jfs2/src/RMI/Public/libs/log4cxx-0.9.8/src/
objectimpl.cp
p:39
I've reviewed the code for ObjectImpl and it looks like it should
force the APRInitializer destructor to occur after the last object
has been released, however the stack trace looks like what might
happen if an apr_atomic_dec is called after apr_terminate has been
called.
Could you check whether apr_terminate is called before the stack
trace occurs? It should be called from src/aprinitializer.cpp after
all log4cxx object have been destructed. If it is called
prematurely, could you set a breakpoint on APRInitializer::getInstance
() after apr_terminate has been called to see if anybody creates a
new log4cxx object after shutdown.
