Home | History | Annotate | Download | only in docs

Lines Matching full:blocks

23     heap blocks, overrunning the top of the stack, and accessing memory after
34 blocks, or mismatched use of
172 <para>The contents of heap blocks (allocated with
269 <para>Memcheck keeps track of the blocks allocated by your program
347 xreflabel="Overlapping source and destination blocks">
348 <title>Overlapping source and destination blocks</title>
357 The blocks pointed to by their <computeroutput>src</computeroutput> and
371 <para>You don't want the two blocks to overlap because one of them could
436 <para>Memcheck keeps track of all heap blocks issued in response to
439 So when the program exits, it knows which blocks have not been freed.
529 - AAA, BBB: heap blocks
551 <para>"Still reachable". This covers cases 1 and 2 (for the BBB blocks)
555 blocks are very common and arguably not a problem. So, by default,
556 Memcheck won't report such blocks individually.</para>
560 <para>"Definitely lost". This covers case 3 (for the BBB blocks) above.
569 <para>"Indirectly lost". This covers cases 4 and 9 (for the BBB blocks)
571 pointers to it, but rather because all the blocks that point to it are
575 indirect leak is fixed, Memcheck won't report such blocks individually
580 <para>"Possibly lost". This covers cases 5--8 (for the BBB blocks)
604 definitely lost: 48 bytes in 3 blocks.
605 indirectly lost: 32 bytes in 2 blocks.
606 possibly lost: 96 bytes in 6 blocks.
607 still reachable: 64 bytes in 4 blocks.
608 suppressed: 0 bytes in 0 blocks.
611 <para>If heuristics have been used to consider some blocks as
620 definitely lost: 4 bytes in 1 blocks
621 indirectly lost: 0 bytes in 0 blocks
622 possibly lost: 0 bytes in 0 blocks
623 still reachable: 95 bytes in 6 blocks
625 stdstring : 56 bytes in 2 blocks
626 length64 : 16 bytes in 1 blocks
627 newarray : 7 bytes in 1 blocks
628 multipleinheritance: 8 bytes in 1 blocks
629 suppressed: 0 bytes in 0 blocks
635 blocks that have the same leak kind and sufficiently similar stack traces
641 have any definitely lost or possibly lost blocks at exit.</para>
645 8 bytes in 1 blocks are definitely lost in loss record 1 of 14
650 88 (8 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 13 of 14
659 bytes in other blocks are indirectly lost because of this lost block.
662 in the Valgrind gdbserver to list the addresses of the leaked blocks and/or give
690 <para>To also show the reachable and indirectly lost blocks in
691 addition to the definitely and possibly lost blocks, you can
693 reachable and indirectly lost blocks, use
695 and indirectly lost blocks will then be presented as shown in
699 64 bytes in 4 blocks are still reachable in loss record 2 of 4
704 32 bytes in 2 blocks are indirectly lost in loss record 1 of 4
900 <listitem><para><option>RBk</option> : reachable Blocks</para></listitem>
901 <listitem><para><option>PBk</option> : Possibly lost Blocks</para></listitem>
902 <listitem><para><option>IBk</option> : Indirectly lost Blocks</para></listitem>
903 <listitem><para><option>DBk</option> : Definitely lost Blocks</para></listitem>
1052 free'd blocks.
1084 of blocks and/or allocates/frees from many different stack
1087 related to heap blocks.
1119 and placed in a queue of freed blocks. The purpose is to defer as
1123 accesses to blocks for some significant period of time after they
1127 blocks in the queue. The default value is twenty million bytes.
1130 blocks which would otherwise go undetected.</para>
1134 <varlistentry id="opt.freelist-big-blocks" xreflabel="--freelist-big-blocks">
1136 <option><![CDATA[--freelist-big-blocks=<number> [default: 1000000] ]]></option>
1139 <para>When making blocks from the queue of freed blocks available
1140 for re-allocation, Memcheck will in priority re-circulate the blocks
1141 with a size greater or equal to <option>--freelist-big-blocks</option>.
1142 This ensures that freeing big blocks (in particular freeing blocks bigger than
1144 of all (or a lot of) the small blocks in the free list. In other words,
1146 for the "small" blocks, even when big blocks are freed.</para>
1147 <para>Setting a value of 0 means that all the blocks are re-circulated
1211 <para>When enabled, Memcheck checks that heap blocks are
1214 used to deallocate blocks allocated
1216 blocks allocated by <varname>new</varname>,
1217 and <varname>delete[]</varname> for blocks allocated
1259 <para>Fills blocks allocated
1279 <para>Fills blocks freed
1406 and blocks suppressed by the suppression.
1407 If the run contains multiple leak checks, the number of bytes and blocks
1410 <para>In the example below, in the last leak search, 7 blocks and 96 bytes have
1414 --21041-- used_suppression: 10 some_other_leak_suppression s.supp:14 suppressed: 12,400 bytes in 1 blocks
1415 --21041-- used_suppression: 39 some_leak_suppression s.supp:2 suppressed: 96 bytes in 7 blocks
1741 the block in the freed-blocks-queue. The aim is to defer as long
1901 detailed information for each leak: the stack trace where the leaked blocks
1902 were allocated, the number of blocks leaked and their total size. When a
1920 <para>The <varname>kinds</varname> argument controls what kind of blocks
1928 possibly leaked blocks, .i.e those for which only an interior
1946 blocks since the previous leak check should be shown. The
1966 ==19520== 16 (+16) bytes in 1 (+1) blocks are possibly lost in loss record 9 of 12
1973 ==19520== definitely lost: 32 (+0) bytes in 2 (+0) blocks
1974 ==19520== indirectly lost: 16 (+0) bytes in 1 (+0) blocks
1975 ==19520== possibly lost: 32 (+16) bytes in 2 (+1) blocks
1976 ==19520== still reachable: 96 (+16) bytes in 6 (+1) blocks
1977 ==19520== suppressed: 0 (+0) bytes in 0 (+0) blocks
1978 ==19520== Reachable blocks (those to which a pointer was found) are not shown.
1983 ==19520== definitely lost: 32 (+0) bytes in 2 (+0) blocks
1984 ==19520== indirectly lost: 16 (+0) bytes in 1 (+0) blocks
1985 ==19520== possibly lost: 32 (+0) bytes in 2 (+0) blocks
1986 ==19520== still reachable: 96 (+0) bytes in 6 (+0) blocks
1987 ==19520== suppressed: 0 (+0) bytes in 0 (+0) blocks
1988 ==19520== Reachable blocks (those to which a pointer was found) are not shown.
1997 blocks. You can obtain the same information without rerunning by
2009 shows the list of blocks belonging to
2012 The nr of blocks to print can be controlled using the
2014 of blocks to output.
2016 and blocks found via one of the given <varname>heur1,heur2,...</varname>
2020 <para> A leak search merges the allocated blocks in loss records :
2021 a loss record re-groups all blocks having the same state (for
2026 followed by the addresses and sizes of the blocks which have been
2031 <para> If a directly lost block causes some other blocks to be indirectly
2032 lost, the block_list command will also show these indirectly lost blocks.
2033 The indirectly lost blocks will be indented according to the level of indirection
2047 loss of blocks B to G. The first block_list command shows the loss record of A
2049 of the indirectly lost blocks due to block A are shown below the block A.
2065 ==19552== 112 (16 direct, 96 indirect) bytes in 1 blocks are definitely lost in loss record 7 of 7
2072 ==19552== definitely lost: 16 bytes in 1 blocks
2073 ==19552== indirectly lost: 96 bytes in 6 blocks
2074 ==19552== possibly lost: 0 bytes in 0 blocks
2075 ==19552== still reachable: 0 bytes in 0 blocks
2076 ==19552== suppressed: 0 bytes in 0 blocks
2079 ==19552== 112 (16 direct, 96 indirect) bytes in 1 blocks are definitely lost in loss record 7 of 7
2092 ==19552== 16 bytes in 1 blocks are indirectly lost in loss record 2 of 7
2164 ==3748== 8 bytes in 1 blocks are possibly lost in loss record 6 of 7
2237 number of blocks since the previous leak search. It has no return
2245 bytes or leaked number of blocks since the previous leak search. It
2268 number of blocks rather than the number of bytes in each
2435 blocks using <varname>VALGRIND_MALLOCLIKE_BLOCK</varname>.
2437 level is the blocks described
2439 level blocks are described
2442 blocks is implicit : second level blocks will be located
2443 inside first level blocks. It is necessary to use
2446 overlapping memory blocks, and will abort execution
2458 will automatically free the second level blocks that are
2464 second level blocks included in the first level block.