From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19407 invoked by alias); 30 Apr 2012 14:28:43 -0000 Received: (qmail 19396 invoked by uid 22791); 30 Apr 2012 14:28:42 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Apr 2012 14:28:29 +0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/53169] Memory leak in std::vector Date: Mon, 30 Apr 2012 14:28:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Keywords: X-Bugzilla-Severity: critical X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-04/txt/msg02618.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53169 --- Comment #1 from Jonathan Wakely 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