How a weak_ptr might prevent full memory cleanup of managed object

When I was working on the Smart Pointer Reference Card I run into a quite interesting issue. It appears that in some cases memory allocated for the object controlled by smart_ptr might not be released until all weak pointers are also ‘dead’.

Such case was surprising to me because I thought that the moment the last share_ptr goes down, the memory is released.

Let’s drill down the case. It might be interesting as we’ll learn how shared/weak pointers interact with each other.

The use case  

Ok, so what’s the problem?

First, we need to see the elements of the case:

• a managed object, let’s assume it’s big (as sizeof would report)
  • Object might contain other pointers/containers that can allocate own memory chunks, so they don’t contribute much to the final object size (apart from a few pointers). For example std::vectoruses allocates memory for the stored elements.
• shared_ptr (one or more) - they point to the above object (resource)
• make_shared - used to create a shared pointer
• weak_ptr
• the control block of shared/weak pointers

The code is simple:

Shared pointers to our large object go out of the scope. The reference counter reaches 0, and the object can be destroyed. But there’s also one weak pointer that outlives shared pointers.

weak_ptr<MyLargeType> weakPtr;
{
	auto sharedPtr = make_shared<MyLargeType>();
	weakPtr = sharedPtr;
	// ...
}
cout << "scope end...\n";

In the above code we have two scopes: inner - where the shared pointer is used, and outer - with a weak pointer (notice that this weak pointer holds only a ‘weak’ reference, it doesn’t use lock() to create a strong reference).

When the shared pointer goes out the scope of the inner block it should destroy the managed object… right?

This is important: when the last shared pointer is gone this destroys the objects in the sense of calling the destructor of MyLargeType (this will also release memory for members that allocate their separate memory chunks, like vectors, strings, etc)… but what about the allocated memory for the object? Can we also release it?

To answer that question let’s consider the second example:

weak_ptr<MyLargeType> weakPtr;
{
	shared_ptr<MyLargeType> sharedPtr(new MyLargeType());
	weakPtr = sharedPtr;
	// ...
}
cout << "scope end...\n";

Almost the same code… right? The difference is only in the approach to create the shared pointer: here we use explicit new.

Let’s see the output when we run both of those examples.

In order to have some useful messages, I needed to override global new and delete, plus report when the destructor of my example class is called.

void* operator new(size_t count) {
	cout << "allocating " << count << " bytes\n";
	return malloc(count);
}

void operator delete(void* ptr) noexcept {
	cout << "global op delete called\n";
	free(ptr);
}

struct MyLargeType {
	~MyLargeType() { cout << "destructor MyLargeType\n"; }

private: 
	int arr[100]; // wow... so large!!!!!!
};

Ok, ok… let’s now see the output:

For make_shared:

allocating 416 bytes
destructor MyLargeType
scope end...
global op delete called

and for the explicit new case:

allocating 400 bytes
allocating 24 bytes
destructor MyLargeType
global op delete called
scope end...
global op delete called

What happens here?

The first important observation is that, as you might already know, make_shared will perform just one memory allocation. With the explicit new we have two separate allocations.

So we need a space for two things: the object and… the control block.

The control block is implementation depended, but it holds the pointer to an object and also the reference counter. Plus some other things (like custom deleter, allocator, …).

When we use explicit new, we have two separate blocks of memory. So when the last shared pointer is gone, then we can destroy the object and also release the memory.

So we see the output:

destructor MyLargeType
global op delete called

Both the destructor and free() is called - before the scope ends.

However, when a shared pointers is created using make_shared() then the managed object resides in the same memory block as the rest of the implementation details.

Here’s a picture with that idea:

The thing is that when you create a weak pointer, then inside the control block “weak counter” is usually increased. Weak pointers and shared pointers need that mechanism so that they can answer the question “is the pointer dead or not yet”, (or to call expire() method).

In other words we cannot remove the control block if there’s a weak pointer around (while all shared pointers are dead). So if the managed object is allocated in the same memory chunk, we cannot release memory for it as well - we cannot free just part of the memory block (at least not that easily).

Below you can find some code from MSVC implementation, this code is called from the destructor of shared_ptr (when it’s created from make_shared):

~shared_ptr() _NOEXCEPT
{   // release resource
	this->_Decref();
}

void _Decref()
{    // decrement use count
	if (_MT_DECR(_Uses) == 0)
	{    // destroy managed resource, 
		// decrement weak reference count
		_Destroy();
		_Decwref();
	}
}

void _Decwref()
{    // decrement weak reference count
	if (_MT_DECR(_Weaks) == 0)
	{
		_Delete_this();
	}
}

As you see there’s separation of Destroying the object - that only calls destructor, and Delete_this() - only occurs when the weak count is zero.

Here’s the link if you want to play with the code: Coliru example.

Fear not!  

The story of memory allocations and clean up is interesting… but does it affect us that much?

Possibly not much.

You shouldn’t stop using make_shared just because of that reason! :)

The thing is that it’s quite a rare situation.

Still, it’s good to know this behaviour and keep it in mind when implementing some complex systems that rely on shared and weak pointers.

For example, I am thinking about the concurrent weak dictionary data structure presented by Herb Sutter: My Favorite C++ 10-Liner | GoingNative 2013 | Channel 9.

Correct me if I’m wrong:

make_shared will allocate one block of memory for the control block and for the widget. So when all shared pointers are dead, the weak pointer will live in the cache… and that will also cause the whole memory chunk to be there as well. (Destructors are called, but memory cannot be released).

To enhance the solution, there should be some additional mechanism implemented that would clean unused weak pointers from time to time.

Remarks  

After I understood the case I also realized that I’m a bit late with the explanation - others have done it in the past :) Still, I’d like to note things down.

So here are some links to resources that also described the problem:

• Effective Modern C++ - item 21 - “Prefer std::make_unique and std::make_shared to direct use of new.”
• Make_shared, almost a silver bullet | I will not buy this blog, it is scratched!.

From Effective Modern C++, page 144:

As long as std::weak_ptrs refer to a control block (i.e., the weak count is greater than zero), that control block must continue to exist. And as long as a control block exists, the memory containing it must remain allocated. The memory allocated by a std::shared_ptr make function, then, can’t be deallocated until the last std::shared_ptr and the last std::weak_ptr referring to it have been destroyed.

Summary  

The whole article was a fascinating investigation to do!

Sometimes I catch myself spending too much time on things that maybe are not super crucial. Still, they are engaging. It’s great that I can share this as a blog post :)

The bottom line for the whole investigation is that the implementation of shared and weak pointers is quite complex. When the control block is allocated in the same memory chunk as the managed object, a special care has to be taken when we want to release the allocated memory.

Remember that such behaviour of shared_ptr/make_shared is not a major “flaw” and you should be still using them! Just be aware that if you have some weak_ptr around and you really care about memory then special care needs to be taken.

BTW: with this exercise, I needed to look at the code behind shared_ptr… it’s not super simple! Have you seen this? Or maybe you wrote a similar smart pointer?