id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
2700,Severe bug in interprocess/smart_ptr/detail/sp_counted_impl.hpp,Lars Hagström <lars@…>,Ion Gaztañaga,"I believe that there is a bug in sp_counted_impl_pd::destroy(). Currently the method looks like this:

{{{
void destroy() // nothrow
{
  //Self destruction, so get a copy of the allocator
  //(in the future we could move it)
  this_allocator a_copy(*this);
  BOOST_ASSERT(a_copy == *this);
  this_pointer this_ptr (this);
  //Do it now!
  scoped_ptr<this_type, 
             scoped_ptr_dealloc_functor<this_allocator> >
    (this_ptr, a_copy);
  typedef typename this_allocator::value_type value_type;
  detail::get_pointer(this_ptr)->~value_type();
}
}}}

What I think is wrong is on the deallocator functor line.
I believe that it should read
{{{
  scoped_ptr<this_type, 
             scoped_ptr_dealloc_functor<this_allocator> >
    DEALLOCATOR(this_ptr, a_copy);
}}}
The missing thing is the name for the scoped_ptr instance (the one I called DEALLOCATOR, to make it stand out). And since the name is missing it will become an anonymous instance, which will be destroyed '''before''' the destructor is called on this_ptr.

The upshot is that with the bug we deallocate the memory and then call the destructor, rather than the opposite. If you're unlucky some other thread/process has allocated that memory for some other use, and you will then be running the destructor on that instead...

I've found this in boost 1.35, but as far as I can see it is not fixed in later versions or in the trunk.",Bugs,closed,Boost 1.38.0,interprocess,Boost 1.35.0,Showstopper,fixed,,