[Bug libstdc++/53169] Memory leak in std::vector<std::vector*>

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53169

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-30 14:28:11 UTC ---
(In reply to comment #0)
> The attached source is a minimal test case, implementing a sparse array of
> std::vectors in class Collection, and test() demonstrates its use in a memory
> neutral way (all allocated objects are freed).

Unless you call Collection::at(n) twice for the same n, in which case you leak
raw[n]

> When compiled on x86-64 linux with gcc 4.6.1, gcc 4.7.1 and clang 3.0 (using
> GNU libstdc++), tools such as top show that memory increases when running
> test(), but does not not decrease after the function exits:

That's how GNU/Linux works.  A process' memory will not decrease, but that
doesn't mean it's leaked. 


> 500Mb are lost in
> this test case. Just increase to loop count and make that 4Gb if you wish: the
> amount of  leaked memory don't seem to be bounded.
> `valgrind --leak-check=full ./a.out` reports there is not a single byte leaked,
> which I double checked with the heap profiler from google perf tools.

Indeed. No memory is leaked. The memory is returned to the heap and will be
available for further allocations.

> The memory is reserved by libstdc++ and unavailable to other processes or

It's virtual memory, if you delete it then it's available to other processes,
even if your process' memory usage doesn't appear to have decreased according
to top.

> subsequent malloc/frees within the same program. Subsequent C++ STL allocations
> (e.g. resizing a big vector) on the other hand don't register on process memory
> and seem to ruse the reserved buffers; sometimes they even trigger deallocation
> of the "leaked" memory.

In the default configuration libstdc++ just uses new/delete which uses malloc,
i.e. there's no memory caching in libstdc++ allocators
You can see this for yourself in include/ext/new_allocator.h