This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug malloc/14581] glibc leaks memory and do not reuse after free (leading to unlimited RSS growth)
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Fri, 14 Sep 2012 19:26:39 +0000
- Subject: [Bug malloc/14581] glibc leaks memory and do not reuse after free (leading to unlimited RSS growth)
- Auto-submitted: auto-generated
- References: <bug-14581-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=14581
Rich Felker <bugdal at aerifal dot cx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugdal at aerifal dot cx
--- Comment #1 from Rich Felker <bugdal at aerifal dot cx> 2012-09-14 19:26:39 UTC ---
Is this supposed to be a bug report or a trick question for CS students? :) You
claimed "there is no heap fragmentation", but the allocation/free pattern
you're performing seems like a classic fragmentation stress test pattern. There
is no general-purpose allocation strategy that can avoid all instances of
pathological fragmentation, and this pattern is one that would be especially
hard to avoid without having special-cased it (and probably making malloc
behavior much worse for common real-world cases). Did you run into this issue
in a real-world application, or did you construct this test as a worst-case?
By the way, the pathological fragmentation observed here does not seem specific
to glibc. It seems like it will occur with any allocator utilizing the basic
dlmalloc strategy. I just confirmed that the same issue happens with ours in
musl libc.
--
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.