http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58659

            Bug ID: 58659
           Summary: Construction of shared_ptr from unique_ptr mismatches
                    new/delete and std::allocator for __shared_ptr_count
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: spencer at starscale dot com
                CC: jwakely.gcc at gmail dot com

Using gcc-4.8.1 configured with --enable-threads=single
--enable-libstdcxx-allocator=mt, I'm seeing the following tiny program
crash:

int
main()
{
  std::unique_ptr<X> u = std::unique_ptr<X>(new X);
  std::shared_ptr<X> s(std::move(u));
  return 0;
}

Note that I am using a different default std::allocator base class
(not new/delete).

I think the bug is that the shared_ptr count object is being allocated
with new and deleted with std::allocator.  This will work when
std::allocator is new/delete, but not otherwise.

I haven't had time to prove it or work up a patch yet; I can if that
helps: please let me know.

Look at __shared_ptr_base's __S_create_from_up:

template<typename _Tp, typename _Del>
  static _Sp_counted_base<_Lp>*
  _S_create_from_up(std::unique_ptr<_Tp, _Del>&& __r,
    typename std::enable_if<!std::is_reference<_Del>::value>::type* =
  0)
  {
    typedef typename unique_ptr<_Tp, _Del>::pointer _Ptr;
    return new _Sp_counted_deleter<_Ptr, _Del, std::allocator<void>,
      _Lp>(__r.get(), __r.get_deleter());
  }

It always uses "new" to allocate an _Sp_counted_deleter (in both
overloads).  I think this is the bug, because _Sp_counted_deleter
always uses std::allocator to dispose of itself:

virtual void
_M_destroy() noexcept
{
  typedef typename allocator_traits<_Alloc>::template
    rebind_traits<_Sp_counted_deleter> _Alloc_traits;
  typename _Alloc_traits::allocator_type __a(_M_del);
  _Alloc_traits::destroy(__a, this);
  _Alloc_traits::deallocate(__a, this, 1);
}

CC Jonathan Wakely who has already analyzed this with a test case for the stock
std::allocator on the mailing list.

Reply via email to