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

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

http://sourceware.org/bugzilla/show_bug.cgi?id=14581

--- Comment #8 from Rich Felker <bugdal at aerifal dot cx> 2012-09-16 12:46:01 UTC ---
> It's very simple. There is RSS and VSZ in /proc/pid/status.
> RSS tells you how much physical memory was really allocated by kernel. If you
> add memset() of objects after being allocated you will find that it's really
> 700MB which corresponds to VSZ as well. i.e. this memory is committed.

Of course, but it can't show you gaps in the heap, only the total size of the
heap.

> First 500 iterations are not interesting that much, cause they do not free any
> previously allocated objects.
> Have you noticed that array index wraps after NL and NS iterations passed and
> then most interesting begins?

That's why my experiment on paper had NL=4, to see quickly what happens after
the index wraps.

> Actually, theoretically any allocator should not ever allocate physical RAM
> more then 2*allocated_size due to fragmentation on pattern like this, right?

No, the theoretical limit is many orders of magnitude worse, especially with
alignment constraints. Picture wanting to allocate an object of size K, but
with N objects of size 1 spaced evenly every K-1 units. In this case you have
N*(K-1) units of memory "free", but unable to accommodate the size-K object,
thus requiring new heap space for it. This fragmentation can grow unboundedly;
N can be made arbitrarily large. Also, the size-1 objects can be spaced even
farther apart and still block out allocation of a size-K object if the latter
has alignment requirements. I think your test case is one situation where the
alignment issue matters.

-- 
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.