Created attachment 11487 [details] Patch fixing missing accounting of top chunk glibc's malloc_info() function returns wrong numbers in most of the cases. In particular, the `rest` field is 0 most of the time, and inconsistent with malloc_stats(). I believe this bug was introduced in commit commit bb066545063246d6df186f5a5a61303c58c6547d Author: Ulrich Drepper <drepper@redhat.com> Date: Thu Apr 9 05:45:42 2009 +0000 * malloc/malloc.c (malloc_info): New function. when the implementation of malloc_info() was copy-pasted from mallinfo(), and that the two mallinfo() lines + avail = chunksize (ar_ptr->top); + nblocks = 1; /* top always exists */ were forgotten to be copy-pasted. I have attached a patch that fixes the issue.
Thanks for the bug report. Please send patches to libc-alpha. https://sourceware.org/glibc/wiki/Contribution%20checklist
I posted the patch to libc-alpha: https://sourceware.org/ml/libc-alpha/2019-08/msg00011.html
The master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b6d2c4475d5abc05dd009575b90556bdd3c78ad0 commit b6d2c4475d5abc05dd009575b90556bdd3c78ad0 Author: Niklas Hamb�chen <mail@nh2.me> Date: Thu Aug 8 22:02:27 2019 +0200 malloc: Fix missing accounting of top chunk in malloc_info [BZ #24026] 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.
Fixed in glibc 2.31.
.
The release/2.28/master branch has been updated by Arjun Shankar <arjun@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=91d5989356325759503311df67e750b358ef4148 commit 91d5989356325759503311df67e750b358ef4148 Author: Niklas Hamb�chen <mail@nh2.me> Date: Thu Aug 8 22:02:27 2019 +0200 malloc: Fix missing accounting of top chunk in malloc_info [BZ #24026] 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. (cherry picked from commit b6d2c4475d5abc05dd009575b90556bdd3c78ad0)
The release/2.29/master branch has been updated by Arjun Shankar <arjun@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c6e4c3198b0ec78a921bfc03874fca662c5e9599 commit c6e4c3198b0ec78a921bfc03874fca662c5e9599 Author: Niklas Hamb�chen <mail@nh2.me> Date: Thu Aug 8 22:02:27 2019 +0200 malloc: Fix missing accounting of top chunk in malloc_info [BZ #24026] 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. (cherry picked from commit b6d2c4475d5abc05dd009575b90556bdd3c78ad0)
The release/2.30/master branch has been updated by Arjun Shankar <arjun@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=5f620768fbdae75f71af78852be228ad5577623d commit 5f620768fbdae75f71af78852be228ad5577623d Author: Niklas Hamb�chen <mail@nh2.me> Date: Thu Aug 8 22:02:27 2019 +0200 malloc: Fix missing accounting of top chunk in malloc_info [BZ #24026] 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. (cherry picked from commit b6d2c4475d5abc05dd009575b90556bdd3c78ad0)