Lines Matching full:blocks
23 heap blocks, overrunning the top of the stack, and accessing memory after
34 blocks, or mismatched use of
162 <para>The contents of heap blocks (allocated with
259 <para>Memcheck keeps track of the blocks allocated by your program
337 xreflabel="Overlapping source and destination blocks">
338 <title>Overlapping source and destination blocks</title>
347 The blocks pointed to by their <computeroutput>src</computeroutput> and
361 <para>You don't want the two blocks to overlap because one of them could
384 <para>Memcheck keeps track of all heap blocks issued in response to
387 So when the program exits, it knows which blocks have not been freed.
445 - AAA, BBB: heap blocks
467 <para>"Still reachable". This covers cases 1 and 2 (for the BBB blocks)
472 blocks individually unless <option>--show-reachable=yes</option> is
477 <para>"Definitely lost". This covers case 3 (for the BBB blocks) above.
486 <para>"Indirectly lost". This covers cases 4 and 9 (for the BBB blocks)
488 pointers to it, but rather because all the blocks that point to it are
492 indirect leak is fixed, Memcheck won't report such blocks individually
497 <para>"Possibly lost". This covers cases 5--8 (for the BBB blocks)
521 definitely lost: 48 bytes in 3 blocks.
522 indirectly lost: 32 bytes in 2 blocks.
523 possibly lost: 96 bytes in 6 blocks.
524 still reachable: 64 bytes in 4 blocks.
525 suppressed: 0 bytes in 0 blocks.
531 blocks that have the same category and sufficiently similar stack traces
537 have any definitely lost or possibly lost blocks at exit.</para>
541 8 bytes in 1 blocks are definitely lost in loss record 1 of 14
546 88 (8 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 13 of 14
555 bytes in other blocks are indirectly lost because of this lost block.
560 reachable and indirectly lost blocks will also be shown, as the following
564 64 bytes in 4 blocks are still reachable in loss record 2 of 4
569 32 bytes in 2 blocks are indirectly lost in loss record 1 of 4
592 <para>After that, definitely lost and possibly lost blocks are counted as
593 true "errors". Indirectly lost and still reachable blocks are not counted
595 specified and they are printed; this is because such blocks don't need
632 <para>When disabled, the memory leak detector will not show "possibly lost" blocks.
667 lost" and "possibly lost" blocks. When enabled, the leak detector also
668 shows "reachable" and "indirectly lost" blocks. (In other words, it
669 shows all blocks, except suppressed ones, so
778 and placed in a queue of freed blocks. The purpose is to defer as
782 accesses to blocks for some significant period of time after they
786 blocks in the queue. The default value is twenty million bytes.
789 blocks which would otherwise go undetected.</para>
793 <varlistentry id="opt.freelist-big-blocks" xreflabel="--freelist-big-blocks">
795 blocks=<number> [default: 1000000] ]]></option>
798 <para>When making blocks from the queue of freed blocks available
799 for re-allocation, Memcheck will in priority re-circulate the blocks
800 with a size greater or equal to <option>--freelist-big-blocks</option>.
801 This ensures that freeing big blocks (in particular freeing blocks bigger than
803 of all (or a lot of) the small blocks in the free list. In other words,
805 for the "small" blocks, even when big blocks are freed.</para>
806 <para>Setting a value of 0 means that all the blocks are re-circulated
851 <para>Fills blocks allocated
871 <para>Fills blocks freed
1285 the block in the freed-blocks-queue. The aim is to defer as long
1404 each leak: the stack trace where the leaked blocks were allocated,
1405 the number of blocks leaked and their total size. When a full
1416 <para>The second argument controls what kind of blocks are shown for
1419 definitely leaked blocks should be shown. The
1421 leaked blocks (those for which only an interior pointer was
1431 blocks since the previous leak check should be shown. The
1451 ==19520== 16 (+16) bytes in 1 (+1) blocks are possibly lost in loss record 9 of 12
1458 ==19520== definitely lost: 32 (+0) bytes in 2 (+0) blocks
1459 ==19520== indirectly lost: 16 (+0) bytes in 1 (+0) blocks
1460 ==19520== possibly lost: 32 (+16) bytes in 2 (+1) blocks
1461 ==19520== still reachable: 96 (+16) bytes in 6 (+1) blocks
1462 ==19520== suppressed: 0 (+0) bytes in 0 (+0) blocks
1463 ==19520== Reachable blocks (those to which a pointer was found) are not shown.
1468 ==19520== definitely lost: 32 (+0) bytes in 2 (+0) blocks
1469 ==19520== indirectly lost: 16 (+0) bytes in 1 (+0) blocks
1470 ==19520== possibly lost: 32 (+0) bytes in 2 (+0) blocks
1471 ==19520== still reachable: 96 (+0) bytes in 6 (+0) blocks
1472 ==19520== suppressed: 0 (+0) bytes in 0 (+0) blocks
1473 ==19520== Reachable blocks (those to which a pointer was found) are not shown.
1482 blocks. You can obtain the same information without rerunning by
1491 shows the list of blocks belonging to <loss_record_nr>.
1494 <para> A leak search merges the allocated blocks in loss records :
1495 a loss record re-groups all blocks having the same state (for
1500 followed by the addresses and sizes of the blocks which have been
1504 <para> If a directly lost block causes some other blocks to be indirectly
1505 lost, the block_list command will also show these indirectly lost blocks.
1506 The indirectly lost blocks will be indented according to the level of indirection
1520 loss of blocks B to G. The first block_list command shows the loss record of A
1522 of the indirectly lost blocks due to block A are shown below the block A.
1538 ==19552== 112 (16 direct, 96 indirect) bytes in 1 blocks are definitely lost in loss record 7 of 7
1545 ==19552== definitely lost: 16 bytes in 1 blocks
1546 ==19552== indirectly lost: 96 bytes in 6 blocks
1547 ==19552== possibly lost: 0 bytes in 0 blocks
1548 ==19552== still reachable: 0 bytes in 0 blocks
1549 ==19552== suppressed: 0 bytes in 0 blocks
1552 ==19552== 112 (16 direct, 96 indirect) bytes in 1 blocks are definitely lost in loss record 7 of 7
1565 ==19552== 16 bytes in 1 blocks are indirectly lost in loss record 2 of 7
1684 number of blocks since the previous leak search. It has no return
1692 bytes or leaked number of blocks since the previous leak search. It
1715 number of blocks rather than the number of bytes in each
