std::unique_ptr deletes owned object before resetting pointer rather than after. - by Leigh Johnston

Status : 


Sign in
to vote
ID 771887 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 11/21/2012 2:57:20 PM
Access Restriction Public


ISO C++11 mandates that std::unique_ptr<T>::reset() deletes the owned object *after* resetting the pointer to the owned object rather than before as VC10 and VC11 are currently doing.

From unique_ptr modifiers:

"Effects: assigns p to the stored pointer, and then if the old value of the stored pointer, old_p, was not
equal to nullptr, calls get_deleter()(old_p). [ Note: The order of these operations is significant
because the call to get_deleter() may destroy *this. —end note ]"

This can cause a problem if the destructor of the owned object calls back to code which attempts to call reset() a second time on the same unique_ptr object resulting in double delete; workaround is to take a local copy of the unique_ptr object rather than use reset().
Sign in to post a comment.
Posted by Microsoft on 4/29/2014 at 12:31 PM
Thank you for reporting this issue. This issue has been fixed in Visual Studio 2013. You can install a trial version of Visual Studio 2013 with the fix from:
Posted by Microsoft on 12/17/2012 at 5:05 PM

Thanks for reporting this bug. We've fixed it, and the fix will be available in the next release of our C++ Standard Library implementation.

I audited both scalar and array unique_ptr's reset()s and destructors for correctness (fixing additional subtle bugs there). I also added a regression test to make sure that this stays fixed. (I added this alongside an existing regression test for shared_ptr, where an extremely similar bug was fixed in the past.)

Note: Connect doesn't notify me about comments. If you have any further questions, please E-mail me.

Stephan T. Lavavej
Senior Developer - Visual C++ Libraries
Posted by Microsoft on 11/21/2012 at 9:55 PM
Thank you for submitting feedback on Visual Studio and .NET Framework. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by Microsoft on 11/21/2012 at 3:50 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(