From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24259 invoked by alias); 2 Nov 2002 17:06:00 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 24207 invoked by uid 71); 2 Nov 2002 17:06:00 -0000 Resent-Date: 2 Nov 2002 17:06:00 -0000 Resent-Message-ID: <20021102170600.24205.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, bkoz@redhat.com, nathan@codesourcery.com Resent-Reply-To: gcc-gnats@gcc.gnu.org, sefer@hotmail.com Received: (qmail 2620 invoked by uid 61); 2 Nov 2002 17:01:06 -0000 Message-Id: <20021102170106.2619.qmail@sources.redhat.com> Date: Sat, 02 Nov 2002 09:06:00 -0000 From: sefer@hotmail.com Reply-To: sefer@hotmail.com To: gcc-gnats@gcc.gnu.org Cc: bkoz@redhat.com, nathan@codesourcery.com X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31) X-GNATS-Notify: bkoz@redhat.com nathan@codesourcery.com Subject: libstdc++/8430: Found a memory leak in libstdc++-v3 X-SW-Source: 2002-11/txt/msg00100.txt.bz2 List-Id: >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 #include 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 _S_construct_aux char* std::string::_S_construct(char const*, char const*, std::allocator const&, std::forward.......) std::string::_Rep::_S_create(unsigned, std::allocator const&) std::allocator::allocate(unsigned, void const *) std::__default_alloc_template::allocate(unsigned) std::__default_alloc_template::_S_refill(unsigned) std::__default_alloc_template::_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: