Lines Matching full:varname
148 In this example, <varname>x</varname> is uninitialised. Memcheck observes
152 <varname>x</varname> so it can turn it into the corresponding ASCII string,
620 program finishes. If set to <varname>summary</varname>, it says how
621 many leaks occurred. If set to <varname>full</varname> or
622 <varname>yes</varname>, it also gives details of each individual
645 leak report. When set to <varname>low</varname>, only the first
646 two entries need match. When <varname>med</varname>, four entries
647 have to match. When <varname>high</varname>, all entries need to
682 <varname>no</varname> if you don't want to see undefined value
702 to <varname>yes</varname>, Memcheck keeps
709 to <varname>brk</varname>).
750 addressable and others are not. When <varname>yes</varname>, such
756 <para>When <varname>no</varname>, loads from partially invalid
904 <para><varname>Value1</varname>,
905 <varname>Value2</varname>,
906 <varname>Value4</varname>,
907 <varname>Value8</varname>,
908 <varname>Value16</varname>,
914 <para><varname>Cond</varname> (or its old
915 name, <varname>Value0</varname>), meaning use
920 <para><varname>Addr1</varname>,
921 <varname>Addr2</varname>,
922 <varname>Addr4</varname>,
923 <varname>Addr8</varname>,
924 <varname>Addr16</varname>,
930 <para><varname>Jump</varname>, meaning an
935 <para><varname>Param</varname>, meaning an
940 <para><varname>Free</varname>, meaning an
945 <para><varname>Overlap</varname>, meaning a
952 <para><varname>Leak</varname>, meaning
963 <para>The first line of the calling context: for <varname>ValueN</varname>
964 and <varname>AddrN</varname> errors, it is either the name of the function
967 or executable containing the error location. For <varname>Free</varname> errors, is the name
970 <varname>Overlap</varname> errors, is the name of the function with the
1029 uninitialised values from <varname>a[]</varname> into
1030 <varname>b[]</varname>, and doesn't use them in a way which could
1044 at the <varname>j += a[i];</varname>, since at that point the
1080 <para>The question to ask is: how large is <varname>struct S</varname>,
1081 in bytes? An <varname>int</varname> is 4 bytes and a
1082 <varname>char</varname> one byte, so perhaps a <varname>struct
1083 S</varname> occupies 5 bytes? Wrong. All non-toy compilers we know
1084 of will round the size of <varname>struct S</varname> up to a whole
1087 <varname>struct S</varname>'s on some architectures.</para>
1089 <para>So <varname>s1</varname> occupies 8 bytes, yet only 5 of them will
1090 be initialised. For the assignment <varname>s2 = s1</varname>, GCC
1091 generates code to copy all 8 bytes wholesale into <varname>s2</varname>
1096 <varname>s1</varname> into <varname>s2</varname> any way it likes, and a
1304 <para><varname>get_vbits <addr> [<len>]</varname>
1311 by <varname>__</varname> (a double underscore).
1314 In the following example, <varname>string10</varname> is an array
1317 to <varname>string10[5]</varname> is not addressable.
1346 <para><varname>make_memory
1348 [<len>]</varname> marks the range of <len> (default 1)
1350 <varname>noaccess</varname> marks the range as non-accessible, so
1352 <varname>undefined</varname> or <varname>defined</varname> mark
1355 <varname>Definedifaddressable</varname> marks as defined, bytes in
1358 that the first letter of <varname>Definedifaddressable</varname>
1359 is an uppercase D to avoid confusion with <varname>defined</varname>.
1364 <varname>string10</varname> is marked as defined:
1375 <para><varname>check_memory [addressable|defined] <addr>
1376 [<len>]</varname> checks that the range of <len>
1393 <para><varname>leak_check [full*|summary]
1397 </varname>
1398 performs a leak check. The <varname>*</varname> in the arguments
1401 <para> If the first argument is <varname>summary</varname>, only a
1411 the <varname>limited</varname> argument followed by the maximum nr
1417 a <varname>full</varname> leak search. The
1418 value <varname>definiteleak</varname> specifies that only
1420 value <varname>possibleleak</varname> will also show possibly
1423 <varname>reachable</varname> will show all block categories
1428 for a <varname>full</varname> leak search. The
1429 value <varname>increased</varname> specifies that only block
1432 value <varname>changed</varname> specifies that allocation stacks
1434 The value <varname>any</varname> specifies that all leak entries
1436 If <varname>increased</varname> or <varname>changed</varname> are
1442 <varname>leak_check</varname> monitor command on
1443 the <varname>memcheck/tests/leak-cases.c</varname> regression
1490 <para><varname>block_list <loss_record_nr> </varname>
1499 The <varname>block_list</varname> command shows the loss record information
1580 <para><varname>who_points_at <addr> [<len>]</varname>
1589 used in the leak search. So, <varname>who_points_at</varname> can a.o.
1597 in command <varname>block_list</varname>) is shown before the tree was leaked.
1641 <para><varname>VALGRIND_MAKE_MEM_NOACCESS</varname>,
1642 <varname>VALGRIND_MAKE_MEM_UNDEFINED</varname> and
1643 <varname>VALGRIND_MAKE_MEM_DEFINED</varname>.
1650 <para><varname>VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE</varname>.
1651 This is just like <varname>VALGRIND_MAKE_MEM_DEFINED</varname> but only
1656 <para><varname>VALGRIND_CHECK_MEM_IS_ADDRESSABLE</varname> and
1657 <varname>VALGRIND_CHECK_MEM_IS_DEFINED</varname>: check immediately
1667 <para><varname>VALGRIND_CHECK_VALUE_IS_DEFINED</varname>: a quick and easy
1674 <para><varname>VALGRIND_DO_LEAK_CHECK</varname>: does a full memory leak
1681 <para><varname>VALGRIND_DO_ADDED_LEAK_CHECK</varname>: same as
1682 <varname> VALGRIND_DO_LEAK_CHECK</varname> but only shows the
1689 <para><varname>VALGRIND_DO_CHANGED_LEAK_CHECK</varname>: same as
1690 <varname>VALGRIND_DO_LEAK_CHECK</varname> but only shows the
1697 <para><varname>VALGRIND_DO_QUICK_LEAK_CHECK</varname>: like
1698 <varname>VALGRIND_DO_LEAK_CHECK</varname>, except it produces only a leak
1704 <para><varname>VALGRIND_COUNT_LEAKS</varname>: fills in the four
1708 after calling <varname>VALGRIND_DO_LEAK_CHECK</varname> or
1709 <varname>VALGRIND_DO_QUICK_LEAK_CHECK</varname>.</para>
1713 <para><varname>VALGRIND_COUNT_LEAK_BLOCKS</varname>: identical to
1714 <varname>VALGRIND_COUNT_LEAKS</varname> except that it returns the
1720 <para><varname>VALGRIND_GET_VBITS</varname> and
1721 <varname>VALGRIND_SET_VBITS</varname>: allow you to get and set the
1724 <varname>VALGRIND_GET_VBITS</varname>. Only for those who really
1729 <para><varname>VALGRIND_CREATE_BLOCK</varname> and
1730 <varname>VALGRIND_DISCARD</varname>. <varname>VALGRIND_CREATE_BLOCK</varname>
1742 by <varname>VALGRIND_CREATE_BLOCK</varname>. To make this
1743 possible, <varname>VALGRIND_CREATE_BLOCK</varname> returns a
1744 "block handle", which is a C <varname>int</varname> value. You
1745 can pass this block handle to <varname>VALGRIND_DISCARD</varname>.
1748 <varname>VALGRIND_DISCARD</varname> is harmless.
1833 <varname>VALGRIND_MAKE_MEM_NOACCESS</varname> client request.</para>
1853 <varname>VALGRIND_CREATE_MEMPOOL(pool, rzB, is_zeroed)</varname>:
1854 This request registers the address <varname>pool</varname> as the anchor
1856 <varname>rzB</varname>, specifying how large the redzones placed around
1858 <varname>is_zeroed</varname> argument that specifies whether the pool's
1869 <para><varname>VALGRIND_DESTROY_MEMPOOL(pool)</varname>:
1879 <para><varname>VALGRIND_MEMPOOL_ALLOC(pool, addr, size)</varname>:
1880 This request informs Memcheck that a <varname>size</varname>-byte chunk
1881 has been allocated at <varname>addr</varname>, and associates the chunk with the
1883 <varname>pool</varname>. If the pool was created with nonzero
1884 <varname>rzB</varname> redzones, Memcheck will mark the
1885 <varname>rzB</varname> bytes before and after the chunk as NOACCESS. If
1886 the pool was created with the <varname>is_zeroed</varname> argument set,
1893 <para><varname>VALGRIND_MEMPOOL_FREE(pool, addr)</varname>:
1894 This request informs Memcheck that the chunk at <varname>addr</varname>
1896 associated with <varname>addr</varname> as NOACCESS, and delete its
1902 <para><varname>VALGRIND_MEMPOOL_TRIM(pool, addr, size)</varname>:
1903 This request trims the chunks associated with <varname>pool</varname>.
1905 <varname>pool</varname>. Trimming is formally defined as:</para>
1909 <varname>addr..(addr+size-1)</varname> are preserved.</para>
1913 <varname>addr..(addr+size-1)</varname> are discarded, as though
1914 <varname>VALGRIND_MEMPOOL_FREE</varname> was called on them. </para>
1918 <varname>addr..(addr+size-1)</varname>; areas outside the
1921 <varname>VALGRIND_MEMPOOL_FREE</varname>.</para>
1930 <para><varname>VALGRIND_MOVE_MEMPOOL(poolA, poolB)</varname>: This
1932 address <varname>poolA</varname> has moved to anchor address
1933 <varname>poolB</varname>. This is a rare request, typically only needed
1940 <varname>VALGRIND_MEMPOOL_CHANGE(pool, addrA, addrB,
1941 size)</varname>: This request informs Memcheck that the chunk
1942 previously allocated at address <varname>addrA</varname> within
1943 <varname>pool</varname> has been moved and/or resized, and should be
1944 changed to cover the region <varname>addrB..(addrB+size-1)</varname>. This
1954 <para><varname>VALGRIND_MEMPOOL_EXISTS(pool)</varname>:
1956 tracking a mempool at anchor address <varname>pool</varname>. It
