This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
[RFC][PATCH 0/4] malloc_info: minor fixes and improvements [BZ #17039]
- From: Ken Milmore <ken dot milmore at gmail dot com>
- To: libc-alpha at sourceware dot org
- Date: Mon, 30 Apr 2018 22:00:00 +0100
- Subject: [RFC][PATCH 0/4] malloc_info: minor fixes and improvements [BZ #17039]
I've been looking into the malloc_info() function as a way of examining heap fragmentation of running programs. Unfortunately, it has a couple of annoying problems which have both been mentioned already in BZ #17039.
Problem 1: Reported free chunk sizes include the flag bits which are stored in the LSBs of the chunk header. This means they are typically off by a byte or two. These small errors get rolled up into the totals which can lead to a significant amount of error on a heap with lots of free chunks. Exactly how much error is difficult to tell because there is also...
Problem 2: Sizes of the top blocks in each arena are completely omitted from the output. This makes it impossible to tell exactly how much of the heap is allocated and how much is free. This can be seen particularly easily by calling malloc_info() before and after a malloc() near the start of a program: Because the allocation typically comes straight from the top chunk, which is not listed in the output, the reported state of the heap doesn't change at all between the two calls.
The upshot of the above is that despite providing quite detailed information on heap fragmentation, the output of malloc_info() is less accurate than that provided by the older APIs mallinfo() and malloc_stats(), and is difficult to reconcile with them.
The following minor patches are an attempt to rectify the above problems. Included is a unit test which verifies exact agreement between the byte and block counts produced by malloc_info() and mallinfo() after exercising the heap for a bit.
There are several possible ways that the "top" chunk could be represented in the output: I have chosen to add a separate total element, with type="top", for each arena. It could instead be rolled into the <sizes> list anonymously as just another free chunk, which would have the advantage of not changing the schema at all but seems to go against the purpose of providing detailed information. Suggestions or comments welcome.