Re: [Boost-users] Correct way to store shared_ptr objects in a stl::map

From: Ovanes Markarian (om_boost_at_[hidden])
Date: 2007-03-29 13:59:11

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