status changed; resolution set

John Maddock — Thu, 14 Apr 2011 17:41:33 GMT

status new → closed
resolution → invalid

I can reproduce on MSVC, but this seems to be a bug in shifted_ptr:

The order of operations on pool is:

create pool of block size 1.

Allocate 60 blocks

Deallocate 60 blocks

Corruption of pools internal free list occures here >>>>>

Deallocate 60 blocks.

I set a memory breakpoint on the corrupted pool, and shifted pointer is changing the value 4 bytes into the already freed memory, with call stack:

scrap.exe!boost::detail::sp_counted_base::release() Line 100 + 0xd bytes C++ scrap.exe!boost::detail::sh::shifted_ptr_common<node>::~shifted_ptr_common<node>() Line 67 C++ scrap.exe!boost::detail::sh::shifted_ptr_base<node>::~shifted_ptr_base<node>() + 0x2b bytes C++ scrap.exe!boost::detail::sh::shifted_ptr<node>::~shifted_ptr<node>() Line 362 + 0xf bytes C++ scrap.exe!node::~node() Line 39 + 0x1a bytes C++ scrap.exe!boost::detail::sh::shifted<node>::~shifted<node>() Line 224 + 0xf bytes C++

scrap.exe!boost::detail::sh::shifted<node>::`scalar deleting destructor'() + 0x2b bytes C++

scrap.exe!boost::detail::sh::set::release() Line 99 + 0x39 bytes C++ scrap.exe!boost::detail::sh::shifted_ptr<node>::release(bool d) Line 375 + 0xb bytes C++ scrap.exe!boost::detail::sh::shifted_ptr<node>::reset() Line 357 C++ scrap.exe!list::clear() Line 53 C++ scrap.exe!test_shifted_ptr::test_method() Line 99 C++ scrap.exe!test_shifted_ptr_invoker() Line 82 + 0x26 bytes C++ scrap.exe!boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (cdecl*)(void)>(void (void)* & f) Line 56 + 0x2c bytes C++ scrap.exe!boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused,void (__cdecl*)(void)>::invoke() Line 89 + 0x41 bytes C++

I also noted that:

1) If you're calling ordered_malloc then you should use ordered_free to free the memory. 2) Using pool(1) to allocate randomly sized blocks is likely to be very inefficient (worse than malloc/free), it would be much better if each shifted<T> had it's own pool for sizeof(T) chunks, and could therefore allocate 1 chunk at a time using the unordered pool interfaces (malloc and free) as this would be much more efficient. 3) owned_base has a static pool instance - this is not thread safe - which is to say pool is not safe for calling from mutiple threads. You could use singleton_pool<>::malloc/free instead of storing a static pool instance, and this would then be thread safe.

HTH, John.

PS closing down, please reopen if you really think it's a pool bug, but a test case involving just pool would be nice ;-)

Boost C++ Libraries: Ticket #5444: boost::pool<>::ordered_malloc() crash

status changed; resolution set