Is there a MSVC 2013 std::list memory leak?

Question

https://ideone.com/dA1Km2

This is a link to a simple example program. It defines a custom allocator which counts the difference between the allocations and deallocations.

It creates and then destroys an empty std::list.

When it is built with gcc or clang (as in the link) it outputs 0. This is expected - the deallocations should be the same number as the allocations.

However MSVC 2013 outputs 2. Two allocations are made by this empty std::list, which are not deallocated later.

Is this a memory leak? If not, what happens there, and is there a way to really clear the std::list specific memory in msvc?

Answer 1

The leak is in your own code: Your custom_delete fails to call the destructor for the std::list object--it directly calls operator delete to deallocate the memory without invoking the destructor.

If you fix your program to correctly destroy the list, you will observe no leak (the program prints 0):

auto x = custom_new custom_list<int>;
x->~list(); // Destroy the list
custom_delete(x);
std::cout << the_manager.allocations << std::endl;

So, why do you only see the leak with the Visual C++ std::list implementation? The Visual C++ implementation always allocates a sentinel node for empty list objects, to ensure that when a list is moved (or when two lists are swapped), end iterators are not invalidated. The Standard Library implementation(s) that you are using with gcc and clang apparently do not do this.