From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26445 invoked by alias); 14 Sep 2012 09:41:29 -0000 Received: (qmail 26379 invoked by uid 22791); 14 Sep 2012 09:41:27 -0000 X-SWARE-Spam-Status: No, hits=-3.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 14 Sep 2012 09:41:13 +0000 From: "dev at parallels dot com" To: glibc-bugs@sources.redhat.com Subject: [Bug malloc/14581] New: glibc leaks memory and do not reuse after free (leading to unlimited RSS growth) Date: Fri, 14 Sep 2012 09:41:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: malloc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dev at parallels dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-09/txt/msg00114.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=14581 Bug #: 14581 Summary: glibc leaks memory and do not reuse after free (leading to unlimited RSS growth) Product: glibc Version: 2.15 Status: NEW Severity: normal Priority: P2 Component: malloc AssignedTo: unassigned@sourceware.org ReportedBy: dev@parallels.com Classification: Unclassified If you run the program below you will find that it never really allocates more then 100MB of RAM, while it's RSS grows >700MB (and higher if the internal loop made longer): -------------------------- Arena 0: system bytes = 759681024 in use bytes = 75144000 Total (incl. mmap): system bytes = 759681024 in use bytes = 75144000 max mmap regions = 0 max mmap bytes = 0 --------------------------- The same is confirmed by kernel RSS if allocated memory is touched (below only VSZ grows as memory is not touched). Please note, that this program does a VERY simple thing it allocates/frees objects of 2 fixed sizes only and number of objects is strictly limited, there is no heap fragmentation if you print virtual addresses of allocated objects and kernel VMAs, i.e. you will find a huge unused memory extents which are never reused by glibc. So there is no place for excuses for such behavior like fragmentation. Tested on RHEL6.3 (glibc-2.12-1.80.el6_3.5) and on FC16 (glibc-2.14.90-24.fc16.9), FC17 (glibc-2.15). -------------------------------------- #include #include #define LSIZE (65536+4096) #define SSIZE 556 #define NL 500 #define NS 70000 int main(int argc, char **argv) { void * bigalloc[NL]; void * smallalloc[NS]; int bptr = 0; int sptr = 0; int i; memset(bigalloc, 0, sizeof(bigalloc)); memset(smallalloc, 0, sizeof(smallalloc)); for (i = 0; i < (16*1024*1024*1024ULL)/65536; i++) { free(bigalloc[i % NL]); free(smallalloc[i % NS]); smallalloc[i % NS] = malloc(SSIZE); bigalloc[i % NL] = memalign(4096, LSIZE); } malloc_stats(); system("ps axv|fgrep stressalloc"); } -------------------------------------- Linked from https://bugzilla.redhat.com/show_bug.cgi?id=843478 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.