RE: Core file on AIX

Hi Curt,
I'm the one actually trying to debug this issue so I'll spare Ron from
being the middle-man. :)

I've set a break point at the location you asked (actually @ line 49 of
aprinitializer.cpp just to be sure) and it is not being hit prior to the
exception.

Just to get further information about what you mention below, I set a
breakpoint in apr_terminate and then enabled one in apr_atomic_dec32
after it hit this one.

As you suspected, apr_terminate is called and then there is a call to
apr_atomic_32:

Breakpoint 14, 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
297         CHECK(apr_thread_mutex_lock(lock));
(gdb) bt
#0  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
#1  0xd17acf40 in log4cxx::helpers::ObjectImpl::releaseRef
(this=0x2000ef68) at
/mcoa300/shared/jfs2/src/RMI/Public/libs/log4cxx-0.9.8/src/objectimpl.cp
p:39
#2  0xd17f4c98 in
log4cxx::helpers::ObjectPtrT<log4cxx::Level>::~ObjectPtrT
(this=0xf0f61f68)
    at
/mcoa300/shared/jfs2/src/RMI/Public/libs/log4cxx-0.9.8/include/log4cxx/h
elpers/objectptr.h:88
#3  0xd17f6b30 in __static_initialization_and_destruction_0
(__initialize_p=0, __priority=65535)
    at
/mcoa300/shared/jfs2/src/RMI/Public/libs/log4cxx-0.9.8/src/level.cpp:210
#4  0xd17f7160 in global destructors keyed to
_ZNK7log4cxx5Level8getClassEv () at
/mcoa300/shared/jfs2/src/RMI/Public/libs/log4cxx-0.9.8/src/level.cpp:214
#5  0xd1a1a918 in _GLOBAL__FD_liblog4cxx_so () from
/mcoa300/shared/jfs2/src/RMI/Built/debug/ppc/liblog4cxx.so
#6  0xd034f3ac in mod_fini1 () from /usr/lib/libc.a(shr.o)
#7  0xd034f308 in modfini () from /usr/lib/libc.a(shr.o)
#8  0xd034f8e8 in __modfini () from /usr/lib/libc.a(shr.o)
#9  0xd0345e38 in exit () from /usr/lib/libc.a(shr.o)
#10 0x100001f4 in __start ()

So, if I'm reading this right, from #3 in the backtrace above, the
culprit appears to be the destruction of the global LevelPtr objects
declared at the bottom of level.cpp.  In our case this is happening
after apr_terminate is called from the destruction of the APRInitializer
object and so bad things happen.

James


-----Original Message-----
From: Curt Arnold [mailto:carnold@xxxxxxxxxx] 
Sent: Wednesday, March 08, 2006 2:03 PM
To: Log4CXX User
Subject: Re: Core file on AIX

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.