Memcheck: a memory error detector
==19552== 112 (16 direct, 96 indirect) bytes in 1 blocks are definitely lost in loss record 7 of 7
==19552==
at 0x40070B4: malloc (vg_replace_malloc.c:263)
==19552==
by 0x80484D5: mk (leak-tree.c:28)
==19552==
by 0x80484FC: f (leak-tree.c:41)
==19552==
by 0x8048856: main (leak-tree.c:63)
==19552==
==19552== LEAK SUMMARY:
==19552==
definitely lost: 16 bytes in 1 blocks
==19552==
indirectly lost: 96 bytes in 6 blocks
==19552==
possibly lost: 0 bytes in 0 blocks
==19552==
still reachable: 0 bytes in 0 blocks
==19552==
suppressed: 0 bytes in 0 blocks
==19552==
(gdb) monitor block_list 7
==19552== 112 (16 direct, 96 indirect) bytes in 1 blocks are definitely lost in loss record 7 of 7
==19552==
at 0x40070B4: malloc (vg_replace_malloc.c:263)
==19552==
by 0x80484D5: mk (leak-tree.c:28)
==19552==
by 0x80484FC: f (leak-tree.c:41)
==19552==
by 0x8048856: main (leak-tree.c:63)
==19552== 0x4028028[16]
==19552==
0x4028068[16] indirect loss record 1
==19552==
0x40280E8[16] indirect loss record 3
==19552==
0x4028128[16] indirect loss record 4
==19552==
0x40280A8[16] indirect loss record 2
==19552==
0x4028168[16] indirect loss record 5
==19552==
0x40281A8[16] indirect loss record 6
(gdb) mo b 2
==19552== 16 bytes in 1 blocks are indirectly lost in loss record 2 of 7
==19552==
at 0x40070B4: malloc (vg_replace_malloc.c:263)
==19552==
by 0x80484D5: mk (leak-tree.c:28)
==19552==
by 0x8048519: f (leak-tree.c:43)
==19552==
by 0x8048856: main (leak-tree.c:63)
==19552== 0x40280A8[16]
==19552==
0x4028168[16] indirect loss record 5
==19552==
0x40281A8[16] indirect loss record 6
(gdb)
•
who_points_at <addr> [<len>]
shows all the locations where a pointer to addr is found. If len is equal
to 1, the command only shows the locations pointing exactly at addr (i.e. the "start pointers" to addr). If len is > 1,
"interior pointers" pointing at the len first bytes will also be shown.
The locations searched for are the same as the locations used in the leak search. So,
who_points_at
can a.o. be
used to show why the leak search still can reach a block, or can search for dangling pointers to a freed block. Each
location pointing at addr (or pointing inside addr if interior pointers are being searched for) will be described.
In the below example, the pointers to the ’tree block A’ (see example in command
block_list
) is shown before
the tree was leaked. The descriptions are detailed as the option
--read-var-info=yes
was given at Valgrind
startup. The second call shows the pointers (start and interior pointers) to block G. The block G (0x40281A8) is
reachable via block C (0x40280a8) and register ECX of tid 1 (tid is the Valgrind thread id). It is "interior reachable"
via the register EBX.
67