DEV Community

loading...

How a weak_ptr might prevent full memory cleanup of managed object

fenbf profile image Bartlomiej Filipek ・6 min read

Weak pointer and shared pointer

When I was working on the C++ 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.

One note: this article comes from my blog: Bartek's coding blog: How a weak_ptr might prevent full memory cleanup of managed object.

The 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
    • here we care about objects with a large "sizeof()" (as noted in one comment). For example if a class uses some standard containers they will probably allocate separate chunks of memory.
  • 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... but what about the allocated memory? 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:

Control block of shared pointers

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).

As noted in one comment: classes that uses separate memory

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 to coliru 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:

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 have to be taken when we want to release the allocated memory.

BTW: once again here's the link to C++ Smart Pointers Reference Card if you like to download it.

Discussion (8)

pic
Editor guide
Collapse
jakebman profile image
jakebman

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

Unused weak pointers on the stack cannot be cleaned up until their lifetime ends.

A better proposal for this would be to tell programmers to be more mindful of when they let their weak pointers have unnecessarily long lifetimes, or as one of your links puts it: "So if you’re expecting to use weak_ptrs that will outlive your pointed to object and you need your memory back ASAP consider not using make_shared."

Collapse
fenbf profile image
Bartlomiej Filipek Author

this particular quote was for this concurrent weak dictionary. So you could do an additional scan from time to tile and remove weak_pointers.

Collapse
timidger profile image
Preston Carpenter

Ooo, you made me check and Rust has the same memory model for their Rc/Arc as C++'s shared_ptr. This is something I'll have to remember when using either language.

Collapse
fenbf profile image
Bartlomiej Filipek Author

I've just started with Rust... so you're saying that you can end up in a same situation as I described in C++?

Collapse
timidger profile image
Preston Carpenter

Yep! If you look at the Rust Arc/Rc source here you'll see they have the same memory representation.

However, the fix is a little bit less errorprone to write. You simply need to do Rc<Box<WhateverStruct>>

Thread Thread
fenbf profile image
Bartlomiej Filipek Author

ech... and people say that C++ is a complex language :)
Rust also looks scary :)
Thanks for sharing

Thread Thread
timidger profile image
Preston Carpenter

Ha that's a direct link to the source (and that was just to show you the memory layout).

Here's a much more user-friendly view into the non-thread-safe version of shared_ptr (the thread safe version is called Arc):

Collapse
highperformancecoder profile image
Russell Standish

Wow - I didn't realise that make_shared can implement an intrusive shared pointer. I guess it doesn't have to, according to the standard, but it makes sense as an optimisation.

I usually use weak_ptrs to break cycles in object graphs - and this still works, because the weak_ptrs will be destroyed during the object destructor, meaning the memory deallocation will still happen, just not necessarily at the same time as the destructor is called.

What other uses do people use weak_ptrs for?