Re: [Boost-bugs] [Boost C++ Libraries] #5444: boost::pool<>::ordered_malloc() crash

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #5444: boost::pool<>::ordered_malloc() crash
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2011-04-14 17:41:34

#5444: boost::pool<>::ordered_malloc() crash
  Reporter: philippeb8@… | Owner: cnewbold
      Type: Bugs | Status: closed
 Milestone: To Be Determined | Component: pool
   Version: Boost 1.43.0 | Severity: Problem
Resolution: invalid | Keywords:
Changes (by johnmaddock):

  * 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

 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++
 Line 67 C++
 + 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
         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
         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
 (__cdecl*)(void)>(void (void)* & f) Line 56 + 0x2c bytes C++
 (__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 ;-)

Ticket URL: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:06 UTC