[Bug malloc/15321] malloc/free can't give the memory back to kernel when main_arena is discontinous

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=15321

--- Comment #13 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to ma.jiang from comment #12)
> > 
> > We already support foreign sbrk in the main arena, thus we support
> > non-contiguous cases.
> > 
> > This looks like one of those such cases, but instead of a foreign sbrk, we
> > have a foreign mmap.
> > 
> > I'm reopening and looking at it under the debugger to see what really
> > changes if anything.
> Hi all,
>   It's happy to see your replies. The mmap in the test code seems confusing,
> but we are just trying to make a fence in front of brk(to make the main
> arena discoutinuous). This action can be replaced by a normal mmap(which is
> normal in user progarms), providing result address of the mmap is in front
> of brk.
>   I have ported our local patch to glibc-2.24(and it works as expected :) ).
> I'll post it later if you were intereted.

If you are going to post patches please follow the contribution checklist,
particularly the copyright section:
https://sourceware.org/glibc/wiki/Contribution%20checklist

I can confirm that sbrk will fail when it runs across the mmap'd region, and
malloc will fall back to using mmap as MORECORE and set the main_arena as
non-contiguous.

The question which remains is to double check the trimming logic to make sure
it could be capable of undoing that transition to start freeing back to the
original sbrk region.

I don't think it can because this code triggers:

  /*
     Only proceed if end of memory is where we last set it.
     This avoids problems if there were foreign sbrk calls.
   */
  current_brk = (char *) (MORECORE (0));
  if (current_brk == (char *) (av->top) + top_size)

The discontinuity is as-if a foreign sbrk had been applied, and that means we
won't free any memory.

If mmap's keep intersecting the heap of the main_arena, we will see continued
increases in RSS that we can't free without calling malloc_trim() which trims
not just from the top but from all coalesced chunks everywhere.

-- 
You are receiving this mail because:
You are on the CC list for the bug.