Skip to content

mm/heapinfo,memleak: Add timed capture window with leak report & backtrace - #7445

Open
amandeep-samsung wants to merge 2 commits into
Samsung:masterfrom
amandeep-samsung:heapinfo_tool_v1
Open

mm/heapinfo,memleak: Add timed capture window with leak report & backtrace#7445
amandeep-samsung wants to merge 2 commits into
Samsung:masterfrom
amandeep-samsung:heapinfo_tool_v1

Conversation

@amandeep-samsung

@amandeep-samsung amandeep-samsung commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Add a capture window so a task's heap activity can be inspected over a
chosen time period. "heapinfo -c start" arms it (optionally per task
with -p PID), "heapinfo -c stop" prints the report in three sections:

[1] NEW ALLOCATIONS - allocated in the window, still not freed
(address, size, pid, caller and full call backtrace). The leak
candidates.
[2] REALLOCATIONS - older blocks resized in the window, with old
and new size.
[3] FREED - older blocks freed in the window.

Section 1 plus the section 2 differences minus section 3 equals the
per-pid counter delta between stop and start, exactly - entries are
recorded on the same code path that updates the counter, not by
walking the heap. The state lives in the heap structure, the table
is allocated only for the duration of the window. If it fills up,
the report says how many events were dropped.

On top of the capture window, record the allocation call stack in each
heap node so a leak candidate can be tied to the exact code path that
created it, not just its immediate caller. At allocation time the caller
frames are collected with sched_backtrace() and stored in the node header
(the immediate caller in alloc_call_addr plus the deeper frames in
alloc_caller_backtrace[]); the stop report then prints this backtrace next
to each block, so section [1] shows the full path that led to the
allocation. Capture is limited to the task the window is armed for, so the
backtrace routine is not run on other tasks' stacks, and it is confined to
user-space (application) allocations so the frames are application code.

@amandeep-samsung amandeep-samsung changed the title mm/heapinfo:(using nodes walk) Add a heap capture window to find leak in a time range mm/heapinfo:Add a heap capture window to find leak in a time range (using nodes walk) Jul 14, 2026
@amandeep-samsung amandeep-samsung changed the title mm/heapinfo:Add a heap capture window to find leak in a time range (using nodes walk) mm/heapinfo: Add timed capture window with 3-sec leak report & backtrace Aug 4, 2026
Comment thread os/arch/arm/src/armv7-a/Toolchain.defs Outdated
#
# Copyright 2023 Samsung Electronics All Rights Reserved.
#
#

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you remove this whitespace changes?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and please separate commits to merge easily for inside codebase.
the utils are in separate repo.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

@amandeep-samsung amandeep-samsung changed the title mm/heapinfo: Add timed capture window with 3-sec leak report & backtrace mm/heapinfo,memleak: Add timed capture window with leak report & backtrace Aug 24, 2026
…trace

Add a capture window so a task's heap activity can be inspected over a
chosen time period. "heapinfo -c start" arms it (optionally per task
with -p PID), "heapinfo -c stop" prints the report in three sections:

[1] NEW ALLOCATIONS - allocated in the window, still not freed
(address, size, pid, caller and full call backtrace). The leak
candidates.
[2] REALLOCATIONS - older blocks resized in the window, with old
and new size.
[3] FREED - older blocks freed in the window.

Section 1 plus the section 2 differences minus section 3 equals the
per-pid counter delta between stop and start, exactly - entries are
recorded on the same code path that updates the counter, not by
walking the heap. The state lives in the heap structure, the table
is allocated only for the duration of the window. If it fills up,
the report says how many events were dropped.

On top of the capture window, record the allocation call stack in each
heap node so a leak candidate can be tied to the exact code path that
created it, not just its immediate caller. At allocation time the caller
frames are collected with sched_backtrace() and stored in the node header
(the immediate caller in alloc_call_addr plus the deeper frames in
alloc_caller_backtrace[]); the stop report then prints this backtrace next
to each block, so section [1] shows the full path that led to the
allocation. Capture is limited to the task the window is armed for, so the
backtrace routine is not run on other tasks' stacks, and it is confined to
user-space (application) allocations so the frames are application code.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants