Memcheck: a memory error detector
==19520==
suppressed: 0 (+0) bytes in 0 (+0) blocks
==19520== Reachable blocks (those to which a pointer was found) are not shown.
==19520== To see them, add ’reachable any’ args to leak_check
==19520==
(gdb) mo l
==19520== LEAK SUMMARY:
==19520==
definitely lost: 32 (+0) bytes in 2 (+0) blocks
==19520==
indirectly lost: 16 (+0) bytes in 1 (+0) blocks
==19520==
possibly lost: 32 (+0) bytes in 2 (+0) blocks
==19520==
still reachable: 96 (+0) bytes in 6 (+0) blocks
==19520==
suppressed: 0 (+0) bytes in 0 (+0) blocks
==19520== Reachable blocks (those to which a pointer was found) are not shown.
==19520== To see them, add ’reachable any’ args to leak_check
==19520==
(gdb)
Note that when using Valgrind’s gdbserver, it is not necessary to rerun with
--leak-check=full
--show-reachable=yes
to see the reachable blocks. You can obtain the same information without rerunning
by using the GDB command
monitor leak_check full reachable any
(or, using abbreviation:
mo
l f r a
).
•
block_list <loss_record_nr>
shows the list of blocks belonging to <loss_record_nr>.
A leak search merges the allocated blocks in loss records : a loss record re-groups all blocks having the same state
(for example, Definitely Lost) and the same allocation backtrace. Each loss record is identified in the leak search
result by a loss record number. The
block_list
command shows the loss record information followed by the
addresses and sizes of the blocks which have been merged in the loss record.
If a directly lost block causes some other blocks to be indirectly lost, the block_list command will also show these
indirectly lost blocks. The indirectly lost blocks will be indented according to the level of indirection between the
directly lost block and the indirectly lost block(s). Each indirectly lost block is followed by the reference of its loss
record.
The block_list command can be used on the results of a leak search as long as no block has been freed after this
leak search: as soon as the program frees a block, a new leak search is needed before block_list can be used again.
In the below example, the program leaks a tree structure by losing the pointer to the block A (top of the tree). So,
the block A is directly lost, causing an indirect loss of blocks B to G. The first block_list command shows the loss
record of A (a definitely lost block with address 0x4028028, size 16). The addresses and sizes of the indirectly lost
blocks due to block A are shown below the block A. The second command shows the details of one of the indirect
loss records output by the first command.
A
/
\
B
C
/ \
/ \
D
E F
G
(gdb) bt
#0
main () at leak-tree.c:69
(gdb) monitor leak_check full any
66
Содержание BBV
Страница 176: ...Valgrind FAQ Release 3 8 0 10 August 2012 Copyright 2000 2012 Valgrind Developers Email valgrind valgrind org ...
Страница 177: ...Valgrind FAQ Table of Contents Valgrind Frequently Asked Questions 1 ii ...
Страница 302: ...README mips based on newer GCC versions if possible 95 ...
Страница 303: ...GNU Licenses ...
Страница 304: ...GNU Licenses Table of Contents 1 The GNU General Public License 1 2 The GNU Free Documentation License 8 ii ...