On Dec 12, 2006, at 5:22 PM, Stephen Bartnikowski wrote:
Hi,
I'm having a problem on shutdown of my application, but only on
Linux. I've
attached the stack trace of the last thread at the bottom of this
message.
From what I can tell, in frame 3, apr_atomic_casptr is attempting
to lock a
mutex, but the mutex has already been destroyed. This consistently
causes my
application to abort. The mutex is initialized the first time
APRInitializer::getInstance is called.
I'm wondering if the call order could be changed somehow on
destruction.
However, frame 6 of my core dump is showing me that the object being
destroyed is a static class member variable, and I don't have any
control
over when those are initialized or destroyed.
I think it may be related to bug 159, but that bug is reporting a
seg fault,
so I'm not sure if this is related. Does any one have any
suggestions for
working around this?
Thanks,
Steve
There are two scenarios where I have seen this type of problem (three
if you include deviations from spec in earlier gcc's): destruction of
the Level constants (Level::OFF etc) that appear at the end of src/
level.cpp and logging taking place during the destruction of static
objects.
You might try commenting out Level::OFF et al from include/log4cxx/
level.h and the constructors at the bottom of src/level.cpp. log4cxx
shouldn't need them since it uses the equivalent Level::getOff() et
al methods. They have been kept for compatibility with earlier
versions of log4cxx but been problematic and should likely be
removed. I can't tell from the stack trace if you are running into
this problem or something else.
