On Mar 27, 2006, at 5:07 PM, Wyles Eric - ewyles wrote:
Curt, I was able to recreate this consistently using a test
application
and I was actually able to observe it through gdb and get a better
stack
trace (see below). Does this help?
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1342264400 (LWP 15890)]
0x002046c3 in log4cxx::helpers::ObjectPtrT<log4cxx::Logger>::operator=
(this=0xc, [EMAIL PROTECTED]) at objectptr.h:101
101 if (this->p != p.p)
(gdb) bt
#0 0x002046c3 in
log4cxx::helpers::ObjectPtrT<log4cxx::Logger>::operator= (this=0xc,
[EMAIL PROTECTED]) at objectptr.h:101
#1 0x002884f9 in log4cxx::Hierarchy::updateParents (this=0x9b1fbd0,
[EMAIL PROTECTED]) at
/home/ewyles/ags1.0code/log4cxx/src/hierarchy.cpp:327
...
If you could file a bug and attach the test application and describe
the platform (OS, compiler, processor type and number), it would be
very helpful. The stack trace looks unlike the previous one that
ended up in pthread, might not be the same problem but worth tracking
down.
You previously mentioned that you were using a snapshot build. Was
this problem also observed with the current SVN HEAD?
I don't see an obvious way to get to the state shown by the stack
trace, the newly created logger's parent member appears to be
corrupted or not yet initialized (this=0xc). There is a synchronized
constructor at line 168 in hierarchy.cpp that should have blocked
simultaneous modifications of the same logger, but maybe there is
another path that wasn't guarded. Are all the other threads in
innocuous locations at the time of the fault?
Could you run the test under valgrind? Any diagnostics there?
