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

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

[sefer]

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

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

[bkoz]

Synopsis: Found a memory leak in libstdc++-v3

Responsible-Changed-From-To: unassigned->bkoz
Responsible-Changed-By: bkoz
Responsible-Changed-When: Tue Jan  7 08:29:17 2003
Responsible-Changed-Why:
    Mine.
State-Changed-From-To: open->closed
State-Changed-By: bkoz
State-Changed-When: Tue Jan  7 08:29:17 2003
State-Changed-Why:
    GLIBCPP_FORCE_NEW as put into 3.2.2 for this reason. With this release, you should get accurate results with current valgrind. 
    
    Please see this note for instructions and hints for using valgrind with g++/libstdc++:
    http://gcc.gnu.org/onlinedocs/libstdc++/debug.html

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8430

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

[B. Kosnik]

The following reply was made to PR libstdc++/8430; it has been noted by GNATS.

From: "B. Kosnik" <bkoz@nabi.net>
To: sefer@hotmail.com
Cc: gcc-gnats@gcc.gnu.org, bkoz@redhat.com, nathan@codesourcery.com
Subject: Re: libstdc++/8430: Found a memory leak in libstdc++-v3
Date: Sat, 2 Nov 2002 12:00:30 -0600

 Don't use the default allocators. 
 
 GLIBCPP_FORCE_NEW
 
 http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#6