From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-390338-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 20067 invoked by alias); 30 Apr 2012 14:59:23 -0000
Received: (qmail 20057 invoked by uid 22791); 30 Apr 2012 14:59:22 -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:59:09 +0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/53169] Memory leak in std::vector<std::vector*>
Date: Mon, 30 Apr 2012 14:59: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: <bug-53169-4-B1MksOt9D1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-53169-4@http.gcc.gnu.org/bugzilla/>
References: <bug-53169-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2012-04/txt/msg02620.txt.bz2

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-30 14:59:05 UTC ---
By changing your main to:

int main() {
    test();
    sleep(10);
        char* p = (char*)malloc(1024 * 127);
        for (int i=0; i < 100; ++i)
            p[1024 * i] = 'a' + (i%26);
        sleep(10);
        free(p);
        sleep(10);
    return 0;
}

I see that freeing the small malloc'd memory region (which is below glibc's
MMAP_THRESHOLD value) does actually trigger the earlier new'd memory to be
returned to the system too.

So it's possible to get the memory libstdc+ allocates to be returned to the
system, but it's under the control of glibc, nothing to do with std::vector or
libstdc++

If your memory usage patterns don't result in memory being returned then there
are several posibilities, including not freeing memory when you think you are,
or fragmenting the heap so that later allocations cannot re-use memory returned
to freelists and must allocate new memory using mmap.

Not a GCC bug though.