When CONFIG_MCHECK_HEAP_PROTECTION is enabled, use backtrace_str() to
capture the caller information for each malloc/calloc/realloc/memalign
call. This information is stored in the mcheck header and can be viewed
with 'malloc dump'.
Add a flag to disable the backtrace when the stack is corrupted, since
the backtrace code tries to walks the invalid stack frames and will
crash.
Note: A few allocations made during libbacktrace initialisation may
not have caller info since they occur during the first backtrace call.
Example output showing caller info:
18a1d010 90 used log_init:453 <-board_init_r:774
18a1d0a0 6060 used membuf_new:420 <-console_record
18a3b840 90 used of_alias_scan:911 <-board_init_
Fix up the backtrace test to avoid recursion.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Add a new 'malloc dump' command that walks the dlmalloc heap from start
to end, printing each chunk's address, size (in hex), and status
(used/free/top). This is useful for debugging memory allocation issues.
When CONFIG_MCHECK_HEAP_PROTECTION is enabled, the caller string is
also shown if available.
Example output:
Heap dump: 18a1d000 - 1ea1f000
Address Size Status
----------------------------------
18a1d000 10 (chunk header)
18a1d010 90 used
18adfc30 60 <free>
18adff90 5f3f030 top
1ea1f000 end
----------------------------------
Used: c2ef0 bytes in 931 chunks
Free: 5f3f0c0 bytes in 2 chunks + top
Expand the console-record size to handle this command.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Add counters to track the number of calls to malloc(), free(), and
realloc(). These are displayed by the 'malloc info' command and
accessible via malloc_get_info().
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Add a command to display malloc heap statistics, showing total heap
size and memory currently in use.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>