On Thu, March 29, 2007 19:40, Peter Dimov wrote:
Stephen Torri wrote:
Well when I include in sp_debug_hooks.cpp into my build along with defining -DBOOST_SP_ENABLE_DEBUG_HOOKS in the compiler's command line flags I am seeing a error come up with its destroying the Reader_Factory.
*** errors detected in test suite "Reverse_Impl test suite"; see standard output for details test_one_node_per_section: sp_debug_hooks.cpp:201: void operator delete(void*): Assertion `*pm == allocated_scalar' failed.
[...]
#4 0x006c20ae in operator delete (p=0x8d9f2a8) at sp_debug_hooks.cpp:201
#5 0x006d4983 in __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<unsigned int const, unsigned int> > >::deallocate ( this=0x8d8ae4c, __p=0x8d9f2a8) at
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/ext/new_allocator.h:94
This is an internal std::map deallocation so it should never fail in such a way. I think that it's quite possible that a write through a dangling pointer has corrupted your heap. You might want to switch to valgrind as the problem doesn't appear to be shared_ptr-related (your use seems OK) and valgrind does much more intensive and thorough checks.
I had some similar issue but not with shared_ptr. My problem was the redefinition for debug purposes (to make mem allocation statistics) of the global new operator. In this case the default allocator used the rewritten new operator to allocate container storage and the rewritten operator used the std::allocator and this cycle caused the behaviour. Is there any chance that this might be the cause? Try to write your own allocator for the container, which will forward the calls to really global new. With Kind Regards, Ovanes Markarian