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
ADD_TRACEit uses a combination of pointer address
si[-1].sizethat is inconsistent.
Specifically, the size reported (
si[-1].size) has been modified from what was requested by
ALIGNMENT_SIZEat least once (and
ISC_UNLIKELYa 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 traceentries 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 traceoutput, 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