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 #0 0xffffe410 in __kernel_vsyscall () #1 0xb76fe7d0 in raise () from /lib/libc.so.6 #2 0xb76ffea3 in abort () from /lib/libc.so.6 #3 0xb7ae118e in apr_atomic_casptr () from /usr/local/lib/liblog4cxx.so #4 0xb79fc34d in log4cxx::helpers::ObjectPtrBase::exchange () from /usr/local/lib/liblog4cxx.so #5 0x0805ff67 in ~ObjectPtrT (this=0xb7b7c7e4) at /usr/local/include/log4cxx/helpers/objectptr.h:73 #6 0xb7b63ecc in __tcf_1 () at Message.cpp:14 #7 0xb7701566 in __cxa_finalize () from /lib/libc.so.6 #8 0xb7b63c63 in __do_global_dtors_aux () from /home/sbart/blt/projects/blt/server/blits/server/sdk/impl/libgsutil.so.1_5 #9 0xb7b7556c in _fini () from /home/sbart/blt/projects/blt/server/blits/server/sdk/impl/libgsutil.so.1_5 #10 0xb7f8adc5 in _dl_fini () from /lib/ld-linux.so.2 #11 0xb770126d in exit () from /lib/libc.so.6 #12 0xb76eb884 in __libc_start_main () from /lib/libc.so.6 #13 0x08056201 in _start ()
