From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21619 invoked by alias); 15 Sep 2012 21:00:52 -0000 Received: (qmail 21605 invoked by uid 22791); 15 Sep 2012 21:00:50 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 15 Sep 2012 21:00:38 +0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sources.redhat.com Subject: [Bug malloc/14581] glibc leaks memory and do not reuse after free (leading to unlimited RSS growth) Date: Sat, 15 Sep 2012 21:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: malloc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx 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: In-Reply-To: References: 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/msg00133.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=14581 --- Comment #6 from Rich Felker 2012-09-15 21:00:22 UTC --- Could you explain what you mean by "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"? I'm not aware of any way the kernel VMA data could inform you about heap utilization, which is entirely under userspace control. I did a simulation of your test loop with much smaller sizes using pen and paper, and With SSIZE=2, ALIGN=8, LSIZE=5, NS=[many], NL=4: 3z: SS LLLLLSS LLLLLSS LLLLLSS LLLLL 4a: SS SS LLLLLSS LLLLLSS LLLLL 4z: SSSS SS LLLLLSS LLLLLSS LLLLLLLLLL 5a: SSSS SS SS LLLLLSS LLLLLLLLLL 5z: SSSSSS SS LLLLLSS LLLLLSS LLLLLLLLLL 6a: SSSSSS SS LLLLLSS SS LLLLLLLLLL 6z: SSSSSSSSSS LLLLLSS LLLLLSS LLLLLLLLLL 7a: SSSSSSSSSS LLLLLSS LLLLLSS LLLLL 7z: SSSSSSSSSS LLLLLSS LLLLLSSSS LLLLLLLLLL ... where 3z means "at the end of iteration 3" and 4a means "after the free steps of iteration 4", etc. I might have gotten some details wrong, but it seems this pattern necessarily enforces fragmentation by destroying the alignment potential of each LSIZE-sized free range. Obviously there are some allocation strategies that avoid the issue, but I don't see it being avoidable in dlmalloc-type schemes in general. If you have an idea for how to avoid it without destroying the good properties of the allocator strategy, please share. -- 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.