[PATCH] malloc: Fix missing accounting of top chunk in malloc_info [BZ #24026]

Carlos O'Donell carlos@redhat.com
Thu Aug 1 15:54:00 GMT 2019


On 8/1/19 8:12 AM, Florian Weimer wrote:
> Author: Niklas Hambüchen <mail@nh2.me>
> 
> Fixes `<total type="rest" size="..."> incorrectly showing as 0 most
> of the time.
> 
> The rest value being wrong is significant because to compute the
> actual amount of memory handed out via malloc, the user must subtract
> it from <system type="current" size="...">. That result being wrong
> makes investigating memory fragmentation issues like
> https://bugzilla.redhat.com/show_bug.cgi?id=843478 close to
> impossible.
> 
> [Patch from Bugzilla.  Reformatted for GNU style.]
> 
> 2019-08-01  Niklas Hambüchen  <mail@nh2.me>
> 
> 	[BZ #24026]
> 	* malloc/malloc.c (__malloc_info): Account for top chunk.
> 
> diff --git a/malloc/malloc.c b/malloc/malloc.c
> index 00ce48cf58..1083cd3ef2 100644
> --- a/malloc/malloc.c
> +++ b/malloc/malloc.c
> @@ -5406,6 +5406,10 @@ __malloc_info (int options, FILE *fp)
>   
>         __libc_lock_lock (ar_ptr->mutex);
>   
> +      /* Account for top chunk.  */
> +      avail = chunksize (ar_ptr->top);
> +      nblocks = 1;  /* Top always exists.  */
> +
>         for (size_t i = 0; i < NFASTBINS; ++i)
>   	{
>   	  mchunkptr p = fastbin (ar_ptr, i);
> 

The malloc accounting is quiet complex.

To review this I'd basically have to do a bunch of debugging on
my own to prove this is correct since your proposed patch doesn't
have the required details to validate the change.

Can you post some analysis of a trivial heap and show how this is
a correct fix with before and after numbers?

Can we get a test case that has a trivial setup that shows the fix
is working and in place?

-- 
Cheers,
Carlos.



More information about the Libc-alpha mailing list