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

["antoinep92 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

             Bug #: 53169
           Summary: Memory leak in std::vector<std::vector*>
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: antoinep92@gmail.com


Created attachment 27268
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27268
Test case: 500Mb used after memory neutral function returns!

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

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

The memory is reserved by libstdc++ and unavailable to other processes or
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.
For example when running test() multiple times, the bug only occurs on the
first call. Subsequent calls free memory when done. I guess the reserved memory
is accounted for within libstdc++ internals, and deallocated on finalization
which is why valgrind can't see it.

My application is a sequence of memory intensive operations, and this bug
prevents memory from being freed between steps, and the system quickly runs out
of memory.

Thanks a lot!

*** Note: As this is quite time-critical for me, if someone points me in the
right direction (files, classes involved) I can try to investigate this and
send back a patch.