I'm doubting that its the complexity of the class. More likely that its the "last" class. Also it might be relevant that your using a multicore processor. The library presumes that everything before entering main and after leavnig main is run on a single thread. This seems like a reasonable presumption to me. You might look into this. You should also run the test with break points set on ~singleton(){ m_is_destroyed = true; // <<< break here } To verify that this isn't getting called at an unexpected time. Robert Ramey Robert Mecklenburg wrote:
Robert Ramey writes:
Its currently in the trunk - head version. I can't test it and it doesn't fail on any test platforms, so its up to you guys to test it.
I checked out the trunk and tested some of my code. Of the five classes I tested, four unit tests now pass cleanly. One of them still seg faults with the same stack trace as before.
(gdb) where #0 std::_Rb_tree_rebalance_for_erase (__z=0x8072fb8, __header=@0xb7bfbde0) at ../../../../src/libstdc++-v3/src/tree.cc:337 #1 0xb7bc9f93 in boost::serialization::extended_type_info::key_unregister () from /home/mecklen/work/boost-install/lib/libboost_serialization-gcc42-mt-1_37.so.1.37.0 #2 0xb7bca0ef in boost::serialization::extended_type_info::~extended_type_info () from /home/mecklen/work/boost-install/lib/libboost_serialization-gcc42-mt-1_37.so.1.37.0 #3 0xb7bcaa28 in boost::serialization::detail::extended_type_info_typeid_0::~extended_type_info_typeid_0 () from /home/mecklen/work/boost-install/lib/libboost_serialization-gcc42-mt-1_37.so.1.37.0 #4 0xb7690084 in exit () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7678458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #6 0x0805c0c1 in _start ()
I don't really see any difference between the classes that work versus the one that fails, except that the failure has more nested classes, but it isn't particularly more complex.
Let me know if you want more info on the failing class.
BTW,
Intel(R) Core(TM)2 CPU Ubuntu Hardy Heron g++ 4.2.3
Thanks for all your effort,