RE: Linux deconstruction order problem

> 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.

Hi Curt,

Thanks for the idea.  I gave it shot, but I think my problem is unrelated.

This crash I'm getting is happening with a LoggerPtr object that I've
declared as static.  When the LoggerPtr object is being cleaned up on exit,
the ObjectPtrT destructor is called, which ultimately calls
apr_atomic_casptr that blows up.  It looks like the apr method is trying to
lock a mutex that's already been cleaned up.

If I make the offending LoggerPtr object a class member, exit continues
until the next statically-allocated LoggerPtr object.  Making each LoggerPtr
object a member rather than a static member is less than ideal for my
application, so I'd prefer not to go that route.

Is there a way to de-initialize a statically-allocated LoggerPtr before exit
is called?  Maybe if the static members are allocated with new memory, and
then delete them before exit?  Is there an easier way to get around this?

Thanks!
Steve