The Tech Help You Need

[Curt Arnold <carnold@xxxxxxxxxx>]

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.