Lines Matching full:leak
381 <sect2 id="mc-manual.leaks" xreflabel="Memory leak detection">
382 <title>Memory leak detection</title>
390 <para>If <option>--leak-check</option> is set appropriately, for each
492 indirect leak is fixed, Memcheck won't report such blocks individually
517 <para>The following is an example leak summary.</para>
520 LEAK SUMMARY:
528 <para>If <option>--leak-check=full</option> is specified,
533 <option>--leak-resolution</option> lets you control the
543 by 0x........: mk (leak-tree.c:11)
544 by 0x........: main (leak-tree.c:39)
548 by 0x........: mk (leak-tree.c:11)
549 by 0x........: main (leak-tree.c:25)
566 by 0x........: mk (leak-cases.c:52)
567 by 0x........: main (leak-cases.c:74)
571 by 0x........: mk (leak-cases.c:52)
572 by 0x........: main (leak-cases.c:80)
584 <para>First, a leak is only counted as a true "error" if
585 <option>--leak-check=full</option> is specified. In other words, an
586 unprinted leak is not considered a true "error". If this were not the
614 <varlistentry id="opt.leak-check" xreflabel="--leak-check">
616 <option><![CDATA[--leak-check=<no|summary|yes|full> [default: summary] ]]></option>
623 leak.</para>
632 <para>When disabled, the memory leak detector will not show "possibly lost" blocks.
637 <varlistentry id="opt.leak-resolution" xreflabel="--leak-resolution">
639 <option><![CDATA[--leak-resolution=<low|med|high> [default: high] ]]></option>
642 <para>When doing leak checking, determines how willing
645 leak report. When set to <varname>low</varname>, only the first
650 <para>For hardcore leak debugging, you probably want to use
651 <option>--leak-resolution=high</option> together with
655 <para>Note that the <option>--leak-resolution</option> setting
666 <para>When disabled, the memory leak detector only shows "definitely
667 lost" and "possibly lost" blocks. When enabled, the leak detector also
952 <para><varname>Leak</varname>, meaning
953 a memory leak.</para>
1398 performs a leak check. The <varname>*</varname> in the arguments
1402 summary of the leak search is given; otherwise a full leak report
1403 is produced. A full leak report gives detailed information for
1404 each leak: the stack trace where the leaked blocks were allocated,
1407 kind of leaks to report. A leak's details are shown if they match
1408 both the second and third argument. A full leak report might
1412 of leak records to output. If this maximum is reached, the leak
1417 a <varname>full</varname> leak search. The
1428 for a <varname>full</varname> leak search. The
1431 blocks since the previous leak check should be shown. The
1433 with any change since the previous leak check should be shown.
1434 The value <varname>any</varname> specifies that all leak entries
1437 specified, the leak report entries will show the delta relative to
1438 the previous leak report.
1443 the <varname>memcheck/tests/leak-cases.c</varname> regression
1448 there was no increase since the previous leak search.</para>
1453 ==19520== by 0x80484D5: mk (leak-cases.c:52)
1454 ==19520== by 0x804855F: f (leak-cases.c:81)
1455 ==19520== by 0x80488E0: main (leak-cases.c:107)
1457 ==19520== LEAK SUMMARY:
1467 ==19520== LEAK SUMMARY:
1480 with <option>--leak-check=full</option>
1494 <para> A leak search merges the allocated blocks in loss records :
1497 Each loss record is identified in the leak search result
1511 <para> The block_list command can be used on the results of a leak search as long
1512 as no block has been freed after this leak search: as soon as the program frees
1513 a block, a new leak search is needed before block_list can be used again.
1536 #0 main () at leak-tree.c:69
1540 ==19552== by 0x80484D5: mk (leak-tree.c:28)
1541 ==19552== by 0x80484FC: f (leak-tree.c:41)
1542 ==19552== by 0x8048856: main (leak-tree.c:63)
1544 ==19552== LEAK SUMMARY:
1554 ==19552== by 0x80484D5: mk (leak-tree.c:28)
1555 ==19552== by 0x80484FC: f (leak-tree.c:41)
1556 ==19552== by 0x8048856: main (leak-tree.c:63)
1567 ==19552== by 0x80484D5: mk (leak-tree.c:28)
1568 ==19552== by 0x8048519: f (leak-tree.c:43)
1569 ==19552== by 0x8048856: main (leak-tree.c:63)
1589 used in the leak search. So, <varname>who_points_at</varname> can a.o.
1590 be used to show why the leak search still can reach a block, or can
1610 ==20852== declared at leak-tree.c:35
1616 ==20852== by 0x80484D5: mk (leak-tree.c:28)
1617 ==20852== by 0x8048519: f (leak-tree.c:43)
1618 ==20852== by 0x8048856: main (leak-tree.c:63)
1674 <para><varname>VALGRIND_DO_LEAK_CHECK</varname>: does a full memory leak
1675 check (like <option>--leak-check=full</option>) right now.
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
1698 <varname>VALGRIND_DO_LEAK_CHECK</varname>, except it produces only a leak
1699 summary (like <option>--leak-check=summary</option>).
1706 leak check to be leaked (i.e. the sum of direct leaks and indirect leaks),
2291 <computeroutput>free</computeroutput>d, so it will show up in leak
