[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