memory trace (-m trace) overhaul
In BIND there are as many as three different layers of memory management, including libc. Proper memory account and tracing will need to be able to track any allocation through all of those layers, including how the size and returned address may change through those transitions.
Original issue statement
When
isc__mem_allocate
callsADD_TRACE
it uses a combination of pointer addresssi
and sizesi[-1].size
that is inconsistent.Specifically, the size reported (
si[-1].size
) has been modified from what was requested byALIGNMENT_SIZE
at least once (andISC_UNLIKELY
a second time) while the pointer reported (si
) is offset from the actual base of the allocation by the same amount.This will lead to confusing
-m trace
entries such as:add 0x7f8f6240f018 size 104 file task.c line 1400 mctx 0x55a572544320 ... add 0x7f8f6240f078 size 104 file hash.c line 159 mctx 0x55a572544320
A sharp-eyed reader may notice that there are only 96 bytes between the two reported addresses even though the size reported is 104 bytes.
This is only a "cosmetic error" in the
-m trace
output, so it's automatically low priority.I discovered this in 9.11 and have verified it still exists in both 9.16 and 9.17.
Edit: the merge of jemalloc support in 9.17.17 has changed things, requiring an update to all of these diagrams - consider them to be obsolete unless the comment containing them explicitly mentions being updated for 9.17.17