[Bug malloc/14581] glibc leaks memory and do not reuse after free (leading to unlimited RSS growth)

["bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>]

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.