We recently came across a crash when moving from a unique_ptr to a shared_ptr, using a custom deleter. The crash happened when the pointer used to create the smart pointer was null. Below is code that reproduces the problem, and shows two cases that work.
In the source below, One and Two run happily, while Three crashes in "ReleaseDestroy". The crash appears to be happening when the class being used in the smart pointer has a virtual "Release" and so the program is trying to look up the V-Table. unique_ptr looks like it checks for null pointers and doesn't run the destructor. Shared pointer seems to neglect this.
Does anyone know if this is by design, or is it a bug in the stl implementation? We are using Visual Studio 2015.
#include <iostream>
#include <memory>
template<class R>
void ReleaseDestroy(R* r)
{
r->Release();
};
class FlatDestroy
{
public :
void Release()
{
delete this;
}
};
class VirtualDestroy
{
public:
virtual void Release()
{
delete this;
}
};
class SimpleOne
{
public :
};
void main()
{
std::shared_ptr<SimpleOne> One(nullptr);
std::shared_ptr<FlatDestroy> Two(nullptr, ReleaseDestroy<FlatDestroy>);
std::shared_ptr<VirtualDestroy> Three(nullptr, ReleaseDestroy<VirtualDestroy>);
One.reset();
Two.reset();
Three.reset();
}
The destruction behaviours of unique_ptr
and shared_ptr
are different:
unique_ptr
only calls the deleter if its held pointer is non-null.
shared_ptr
always calls the deleter.
So your shared pointer deleter must be able to deal with null pointer values! For example, std::free
is fine, but std::fclose
is not, and neither is your deleter (since it dereferences r
unconditionally).
Incidentally, this crops up in LWG 2415, which addresses constructing a shared pointer from a unique pointer, which was broken before that defect resolution for exactly that reason. (I hit this problem myself here; note how that code is careful to distinguish the null case for shared_ptr
.)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With