libstdc++/8430: Found a memory leak in libstdc++-v3

[sefer@hotmail.com]

>Number:         8430
>Category:       libstdc++
>Synopsis:       Found a memory leak in libstdc++-v3
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Nov 02 09:06:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     sefer@hotmail.com
>Release:        libstdc++-v3 (with gcc-3.2)
>Organization:
>Environment:
Linux Mandrake 9.0 on x86
>Description:
Apparently I have uncovered a memory leak in the recent libstc++.
Here's a very small test program that was compiled using g++ 3.2 on a x86 Linux machine.

#include <string>
#include <vector>

using namespace std;


int main()
{
	string aaa("a");

	return 0;
}


Running this program under valgrind (both 1.0.4 and 1.1.0) revealed the following report:

> g++ -g2 test.cc

> valgrind --leak-check=yes --show-reachable=yes ./a.out
==15525== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==15525== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==15525== Using valgrind-1.1.0, a program instrumentation system for x86-linux.
==15525== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==15525== Estimated CPU clock rate is 1999 MHz
==15525== For more details, rerun with: -v
==15525== 
==15525== 
==15525== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==15525== malloc/free: in use at exit: 640 bytes in 1 blocks.
==15525== malloc/free: 1 allocs, 0 frees, 640 bytes allocated.
==15525== For counts of detected errors, rerun with: -v
==15525== searching for pointers to 1 not-freed blocks.
==15525== checked 4438348 bytes.
==15525== 
==15525== definitely lost: 0 bytes in 0 blocks.
==15525== possibly lost:   0 bytes in 0 blocks.
==15525== still reachable: 640 bytes in 1 blocks.
==15525== 
==15525== 640 bytes in 1 blocks are still reachable in loss record 1 of 1
==15525==    at 0x40159F4B: __builtin_new (in /opt/valgrind/lib/valgrind/valgrind.so)
==15525==    by 0x40159F87: operator new(unsigned) (vg_clientfuncs.c:140)
==15525==    by 0x4029FBEE: std::__new_alloc::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.0)
==15525==    by 0x4029F7F3: ??? (/home/zvi/t/gcc-3.2/libstdc++-v3/include/bits/stl_alloc.h:481)
==15525== 
==15525== LEAK SUMMARY:
==15525==    definitely lost: 0 bytes in 0 blocks.
==15525==    possibly lost:   0 bytes in 0 blocks.
==15525==    still reachable: 640 bytes in 1 blocks.
==15525== 


Sjowing, that some memory was allocated but was never freed (even when the program had completed its running).
It is possible that the allocator allocates and releases memory during a program's lifetime (maintaining a memory "cache"). However, the proper behaviour for it would be to release all allocated memory at program exit.

This is the stack trace to the allocation call that had never released its memory:

__libc_start_main
main
basic_string
_S_construct<const char *>
_S_construct_aux<const char *>
char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward.......)
std::string::_Rep::_S_create(unsigned, std::allocator<char> const&)
std::allocator<char>::allocate(unsigned, void const *)
std::__default_alloc_template<true, 0>::allocate(unsigned)
std::__default_alloc_template<true, 0>::_S_refill(unsigned)
std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int &)

Now since the memory allocation is global resource, one could possibly create a global object that during its destruction (when the program ends) would clean up all the existing "chunks" of memory, so that the program exits cleanly.


I'd care to hear if anyone had noticed this problem, or have devised some solutions (otherwise, good memory leak detectors would always report leaks on programs using STL).


Thanks,
	Sefer.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: