mm/heapinfo,memleak: Add timed capture window with leak report & backtrace - #7445
Open
amandeep-samsung wants to merge 2 commits into
Open
mm/heapinfo,memleak: Add timed capture window with leak report & backtrace#7445amandeep-samsung wants to merge 2 commits into
amandeep-samsung wants to merge 2 commits into
Conversation
amandeep-samsung
force-pushed
the
heapinfo_tool_v1
branch
from
August 4, 2026 06:13
5b1b7ca to
928fe53
Compare
amandeep-samsung
force-pushed
the
heapinfo_tool_v1
branch
from
August 4, 2026 13:06
928fe53 to
f116f57
Compare
pcs1265
reviewed
Aug 7, 2026
| # | ||
| # Copyright 2023 Samsung Electronics All Rights Reserved. | ||
| # | ||
| # |
Member
There was a problem hiding this comment.
Could you remove this whitespace changes?
Member
There was a problem hiding this comment.
and please separate commits to merge easily for inside codebase.
the utils are in separate repo.
amandeep-samsung
force-pushed
the
heapinfo_tool_v1
branch
from
August 10, 2026 15:17
f116f57 to
ffd07d3
Compare
amandeep-samsung
force-pushed
the
heapinfo_tool_v1
branch
from
August 24, 2026 06:10
ffd07d3 to
b8a4a21
Compare
amandeep-samsung
force-pushed
the
heapinfo_tool_v1
branch
from
August 25, 2026 07:53
b8a4a21 to
fa09cb0
Compare
…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.
amandeep-samsung
force-pushed
the
heapinfo_tool_v1
branch
from
August 25, 2026 16:09
fa09cb0 to
c6b7d2c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.