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: Sat, 15 Sep 2012 21:00:22 +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
--- Comment #6 from Rich Felker <bugdal at aerifal dot cx> 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.