mirror of
https://github.com/Zenithsiz/ftmemsim-valgrind.git
synced 2026-02-03 18:13:01 +00:00
ce806ed31f
about leaked or reachable blocks)
This patch implements two new memcheck gdbserver monitor commands:
block_list <loss_record_nr>
after a leak search, shows the list of blocks of <loss_record_nr>
who_points_at <addr> [<len>]
shows places pointing inside <len> (default 1) bytes at <addr>
(with len 1, only shows "start pointers" pointing exactly to <addr>,
with len > 1, will also show "interior pointers")
Compiled and reg-tested on f12/x86, deb5/amd64, f16/ppc64.
The 'block_list' command is implemented on top of the
lr_array/lc_chunks/lc_extras arrays used during the last leak search.
NB: no impact on the memory for the typical Valgrind usage where a leak
search is only done at the end of the run.
Printing the block_list of a loss record simply consists in scanning the
lc_chunks to find back the chunks corresponding to the loss record for which
block lists is requested.
The 'who_points_at' command is implemented by doing a scan similar to
(but simpler than) the leak search scan.
lc_scan_memory has been enhanced to have a mode to search for a specific
address, rather than to search for all allocated blocks.
VG_(apply_to_GP_regs) has been enhanced to also provide the ThreadId and
register name in the callback function.
The patch touches multiple files (but most changes are easy/trivial or factorise
existing code).
Most significant changes are in memcheck/mc_leakcheck.c :
* changed the LC_Extra struct to remember the clique for indirect leaks
(size of structure not changed).
* made lr_array a static global
* changed lc_scan_memory:
to have a search mode for a specific address (for who_points_at)
(for leak search) to pass a 'current clique' in addition to the clique
leader
so as to have a proper clique hierarchy for indirectly leaked blocks.
* print_results: reset values at the beginning of the print_result of the
next leak search, rather than at the end of print_results of the previous
leak search.
This allows to continue showing the same info for loss records till a new
leak search is done.
* new function print_clique which recursively prints a group of leaked
blocks, starting from the clique leader.
* new function MC_(print_block_list) : calls print_clique for each clique
leader found for the given loss record.
* static void scan_memory_root_set : code extracted from
MC_(detect_memory_leaks) (no relevant change)
* void MC_(who_points_at) : calls scan_memory_root_set, lc_scan_memory
and VG_(apply_to_GP_regs)(search_address_in_GP_reg) to search
pointers to the given address.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12357
68 lines
2.8 KiB
Plaintext
68 lines
2.8 KiB
Plaintext
relaying data between gdb and process ....
|
|
vgdb-error value changed from 0 to 999999
|
|
Breakpoint 1 at 0x........: file leak-tree.c, line 42.
|
|
Breakpoint 2 at 0x........: file leak-tree.c, line 67.
|
|
Continuing.
|
|
Breakpoint 1, f () at leak-tree.c:42
|
|
42 t->l = mk(); // B
|
|
Continuing.
|
|
Breakpoint 2, main () at leak-tree.c:67
|
|
67 PRINT_LEAK_COUNTS(stderr);
|
|
Searching for pointers to 0x........
|
|
*0x........ points at 0x........
|
|
Address 0x........ is 0 bytes inside data symbol "t"
|
|
full leak search
|
|
16 bytes in 1 blocks are still reachable in loss record ... of ...
|
|
at 0x........: malloc (vg_replace_malloc.c:...)
|
|
by 0x........: mk (leak-tree.c:28)
|
|
by 0x........: f (leak-tree.c:41)
|
|
by 0x........: main (leak-tree.c:63)
|
|
16 bytes in 1 blocks are still reachable in loss record ... of ...
|
|
at 0x........: malloc (vg_replace_malloc.c:...)
|
|
by 0x........: mk (leak-tree.c:28)
|
|
by 0x........: f (leak-tree.c:42)
|
|
by 0x........: main (leak-tree.c:63)
|
|
16 bytes in 1 blocks are still reachable in loss record ... of ...
|
|
at 0x........: malloc (vg_replace_malloc.c:...)
|
|
by 0x........: mk (leak-tree.c:28)
|
|
by 0x........: f (leak-tree.c:45)
|
|
by 0x........: main (leak-tree.c:63)
|
|
16 bytes in 1 blocks are indirectly lost in loss record ... of ...
|
|
at 0x........: malloc (vg_replace_malloc.c:...)
|
|
by 0x........: mk (leak-tree.c:28)
|
|
by 0x........: f (leak-tree.c:46)
|
|
by 0x........: main (leak-tree.c:63)
|
|
16 bytes in 1 blocks are indirectly lost in loss record ... of ...
|
|
at 0x........: malloc (vg_replace_malloc.c:...)
|
|
by 0x........: mk (leak-tree.c:28)
|
|
by 0x........: f (leak-tree.c:47)
|
|
by 0x........: main (leak-tree.c:63)
|
|
16 bytes in 1 blocks are definitely lost in loss record ... of ...
|
|
at 0x........: malloc (vg_replace_malloc.c:...)
|
|
by 0x........: mk (leak-tree.c:28)
|
|
by 0x........: f (leak-tree.c:44)
|
|
by 0x........: main (leak-tree.c:63)
|
|
48 (16 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record ... of ...
|
|
at 0x........: malloc (vg_replace_malloc.c:...)
|
|
by 0x........: mk (leak-tree.c:28)
|
|
by 0x........: f (leak-tree.c:43)
|
|
by 0x........: main (leak-tree.c:63)
|
|
block list 6 D
|
|
16 bytes in 1 blocks are definitely lost in loss record ... of ...
|
|
at 0x........: malloc (vg_replace_malloc.c:...)
|
|
by 0x........: mk (leak-tree.c:28)
|
|
by 0x........: f (leak-tree.c:44)
|
|
by 0x........: main (leak-tree.c:63)
|
|
0x........[16]
|
|
block list 7 C F G
|
|
48 (16 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record ... of ...
|
|
at 0x........: malloc (vg_replace_malloc.c:...)
|
|
by 0x........: mk (leak-tree.c:28)
|
|
by 0x........: f (leak-tree.c:43)
|
|
by 0x........: main (leak-tree.c:63)
|
|
0x........[16]
|
|
0x........[16] indirect loss record 4
|
|
0x........[16] indirect loss record 5
|
|
monitor command request to kill this process
|
|
Remote connection closed
|