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

Comment:

 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++
 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 ;-)

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/5444#comment:1>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.