Lines Matching full:varname
158 In this example, <varname>x</varname> is uninitialised. Memcheck observes
162 <varname>x</varname> so it can turn it into the corresponding ASCII string,
405 The <varname>size</varname> argument of the following allocation functions
744 program finishes. If set to <varname>summary</varname>, it says how
745 many leaks occurred. If set to <varname>full</varname> or
746 <varname>yes</varname>, each individual leak will be shown
761 leak report. When set to <varname>low</varname>, only the first
762 two entries need match. When <varname>med</varname>, four entries
763 have to match. When <varname>high</varname>, all entries need to
782 <para>Specifies the leak kinds to show in a <varname>full</varname>
808 <varname>full</varname> leak search. The
943 <varname>no</varname> if you don't want to see undefined value
963 to <varname>yes</varname>, Memcheck keeps
970 to <varname>brk</varname>).
1011 addressable and others are not. When <varname>yes</varname>, such
1017 <para>When <varname>no</varname>, loads from partially invalid
1055 <para>With <varname>alloc-then-free</varname>, a stack trace is
1063 <para>With <varname>alloc-and-free</varname>, both allocation
1067 Compared to <varname>alloc-then-free</varname>, this setting
1072 <para>With <varname>alloc</varname>, only the allocation stack
1073 trace is recorded (and reported). With <varname>free</varname>,
1082 <para>With <varname>none</varname>, no stack traces are recorded
1095 required with the options <varname>--keep-stacktraces</varname>
1097 option <varname>--num-callers</varname>.
1103 specify <varname>--keep-stacktraces=free</varname>
1104 or <varname>--keep-stacktraces=none</varname>.</para>
1213 function. That is, it expects <varname>free</varname> to be
1215 by <varname>malloc</varname>, <varname>delete</varname> for
1216 blocks allocated by <varname>new</varname>,
1217 and <varname>delete[]</varname> for blocks allocated
1218 by <varname>new[]</varname>. If a mismatch is detected, an
1225 <varname>new</varname>/<varname>new[]</varname> that
1226 call <varname>malloc</varname> and
1227 of <varname>delete</varname>/<varname>delete[]</varname> that
1228 call <varname>free</varname>, and these functions are
1230 that <varname>delete[]</varname> is inlined
1231 but <varname>new[]</varname> is not. The result is that
1232 Memcheck "sees" all <varname>delete[]</varname> calls as direct
1233 calls to <varname>free</varname>, even when the program source
1237 reports. <varname>--show-mismatched-frees=no</varname> disables
1312 <para><varname>Value1</varname>,
1313 <varname>Value2</varname>,
1314 <varname>Value4</varname>,
1315 <varname>Value8</varname>,
1316 <varname>Value16</varname>,
1322 <para><varname>Cond</varname> (or its old
1323 name, <varname>Value0</varname>), meaning use
1328 <para><varname>Addr1</varname>,
1329 <varname>Addr2</varname>,
1330 <varname>Addr4</varname>,
1331 <varname>Addr8</varname>,
1332 <varname>Addr16</varname>,
1338 <para><varname>Jump</varname>, meaning an
1343 <para><varname>Param</varname>, meaning an
1348 <para><varname>Free</varname>, meaning an
1353 <para><varname>Overlap</varname>, meaning a
1360 <para><varname>Leak</varname>, meaning
1418 <para>For <varname>ValueN</varname> and <varname>AddrN</varname>
1422 error location. For <varname>Free</varname> errors, the first line is
1425 etc). For <varname>Overlap</varname> errors, the first line is the name of the
1485 uninitialised values from <varname>a[]</varname> into
1486 <varname>b[]</varname>, and doesn't use them in a way which could
1500 at the <varname>j += a[i];</varname>, since at that point the
1536 <para>The question to ask is: how large is <varname>struct S</varname>,
1537 in bytes? An <varname>int</varname> is 4 bytes and a
1538 <varname>char</varname> one byte, so perhaps a <varname>struct
1539 S</varname> occupies 5 bytes? Wrong. All non-toy compilers we know
1540 of will round the size of <varname>struct S</varname> up to a whole
1543 <varname>struct S</varname>'s on some architectures.</para>
1545 <para>So <varname>s1</varname> occupies 8 bytes, yet only 5 of them will
1546 be initialised. For the assignment <varname>s2 = s1</varname>, GCC
1547 generates code to copy all 8 bytes wholesale into <varname>s2</varname>
1552 <varname>s1</varname> into <varname>s2</varname> any way it likes, and a
1760 <para><varname>xb <addr> [<len>]</varname>
1772 by <varname>__</varname> (a double underscore).
1781 In the following example, <varname>string10</varname> is an array
1784 to <varname>string10[5]</varname> is not addressable.
1817 <para><varname>get_vbits <addr> [<len>]</varname>
1820 <varname>xb</varname> command. <varname>get_vbits</varname> only
1823 <varname>xb</varname> command will be easier to use, in particular
1828 The following example shows the result of <varname>get_vibts</varname>
1829 on the <varname>string10</varname> used in the <varname>xb</varname>
1842 <para><varname>make_memory
1844 [<len>]</varname> marks the range of <len> (default 1)
1846 <varname>noaccess</varname> marks the range as non-accessible, so
1848 <varname>undefined</varname> or <varname>defined</varname> mark
1851 <varname>Definedifaddressable</varname> marks as defined, bytes in
1854 that the first letter of <varname>Definedifaddressable</varname>
1855 is an uppercase D to avoid confusion with <varname>defined</varname>.
1860 <varname>string10</varname> is marked as defined:
1871 <para><varname>check_memory [addressable|defined] <addr>
1872 [<len>]</varname> checks that the range of <len>
1889 <para><varname>leak_check [full*|summary|xtleak]
1894 </varname>
1895 performs a leak check. The <varname>*</varname> in the arguments
1898 <para> If the <varname>[full*|summary|xtleak]</varname> argument is
1899 <varname>summary</varname>, only a summary of the leak search is given;
1908 the <varname>limited</varname> argument followed by the maximum nr
1912 <para>The value <varname>xtleak</varname> also produces a full leak report,
1920 <para>The <varname>kinds</varname> argument controls what kind of blocks
1921 are shown for a <varname>full</varname> leak search. The set of leak kinds
1922 to show can be specified using a <varname><set></varname> similarly
1924 Alternatively, the value <varname>definiteleak</varname>
1925 is equivalent to <varname>kinds definite</varname>, the
1926 value <varname>possibleleak</varname> is equivalent to
1927 <varname>kinds definite,possible</varname> : it will also show
1929 pointer was found. The value <varname>reachable</varname> will
1930 show all block categories (i.e. is equivalent to <varname>kinds
1931 all</varname>).
1934 <para>The <varname>heuristics</varname> argument controls the heuristics
1936 using a <varname><set></varname> similarly
1938 The default value for the <varname>heuristics</varname> argument is
1939 <varname>heuristics none</varname>.
1942 <para>The <varname>[increased*|changed|any]</varname> argument controls what
1943 kinds of changes are shown for a <varname>full</varname> leak search. The
1944 value <varname>increased</varname> specifies that only block
1947 value <varname>changed</varname> specifies that allocation stacks
1949 The value <varname>any</varname> specifies that all leak entries
1951 If <varnamevarname> or <varname>changed</varname> are
1957 <varname>leak_check</varname> monitor command on
1958 the <varname>memcheck/tests/leak-cases.c</varname> regression
2005 <para><varname>block_list <loss_record_nr>|<loss_record_nr_from>..<loss_record_nr_to>
2008 </varname>
2010 <varname><loss_record_nr></varname> (or to the loss records range
2011 <varname><loss_record_nr_from>..<loss_record_nr_to></varname>).
2013 <varname>limited</varname> argument followed by the maximum nr
2016 and blocks found via one of the given <varname>heur1,heur2,...</varname>
2025 The <varname>block_list</varname> command shows the loss record information
2107 <para><varname>who_points_at <addr> [<len>]</varname>
2116 used in the leak search. So, <varname>who_points_at</varname> can a.o.
2124 in command <varname>block_list</varname>) is shown before the tree was leaked.
2151 <para> When <varname>who_points_at</varname> finds an interior pointer,
2156 block. <varname>who_points_at</varname> reports that there is an interior
2193 <para><varname>VALGRIND_MAKE_MEM_NOACCESS</varname>,
2194 <varname>VALGRIND_MAKE_MEM_UNDEFINED</varname> and
2195 <varname>VALGRIND_MAKE_MEM_DEFINED</varname>.
2203 <para><varname>VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE</varname>.
2204 This is just like <varname>VALGRIND_MAKE_MEM_DEFINED</varname> but only
2209 <para><varname>VALGRIND_CHECK_MEM_IS_ADDRESSABLE</varname> and
2210 <varname>VALGRIND_CHECK_MEM_IS_DEFINED</varname>: check immediately
2220 <para><varname>VALGRIND_CHECK_VALUE_IS_DEFINED</varname>: a quick and easy
2227 <para><varname>VALGRIND_DO_LEAK_CHECK</varname>: does a full memory leak
2234 <para><varname>VALGRIND_DO_ADDED_LEAK_CHECK</varname>: same as
2235 <varname> VALGRIND_DO_LEAK_CHECK</varname> but only shows the
2242 <para><varname>VALGRIND_DO_CHANGED_LEAK_CHECK</varname>: same as
2243 <varname>VALGRIND_DO_LEAK_CHECK</varname> but only shows the
2250 <para><varname>VALGRIND_DO_QUICK_LEAK_CHECK</varname>: like
2251 <varname>VALGRIND_DO_LEAK_CHECK</varname>, except it produces only a leak
2257 <para><varname>VALGRIND_COUNT_LEAKS</varname>: fills in the four
2261 after calling <varname>VALGRIND_DO_LEAK_CHECK</varname> or
2262 <varname>VALGRIND_DO_QUICK_LEAK_CHECK</varname>.</para>
2266 <para><varname>VALGRIND_COUNT_LEAK_BLOCKS</varname>: identical to
2267 <varname>VALGRIND_COUNT_LEAKS</varname> except that it returns the
2273 <para><varname>VALGRIND_GET_VBITS</varname> and
2274 <varname>VALGRIND_SET_VBITS</varname>: allow you to get and set the
2277 <varname>VALGRIND_GET_VBITS</varname>. Only for those who really
2282 <para><varname>VALGRIND_CREATE_BLOCK</varname> and
2283 <varname>VALGRIND_DISCARD</varname>. <varname>VALGRIND_CREATE_BLOCK</varname>
2295 by <varname>VALGRIND_CREATE_BLOCK</varname>. To make this
2296 possible, <varname>VALGRIND_CREATE_BLOCK</varname> returns a
2297 "block handle", which is a C <varname>int</varname> value. You
2298 can pass this block handle to <varname>VALGRIND_DISCARD</varname>.
2301 <varname>VALGRIND_DISCARD</varname> is harmless.
2386 <varname>VALGRIND_MAKE_MEM_NOACCESS</varname> client request.</para>
2406 <varname>VALGRIND_CREATE_MEMPOOL(pool, rzB, is_zeroed)</varname>:
2407 This request registers the address <varname>pool</varname> as the anchor
2409 <varname>rzB</varname>, specifying how large the redzones placed around
2411 <varname>is_zeroed</varname> argument that specifies whether the pool's
2424 <varname>VALGRIND_CREATE_MEMPOOL_EXT(pool, rzB, is_zeroed, flags)</varname>:
2428 <varname>VALGRIND_CREATE_MEMPOOL</varname>.</para>
2431 <para> The flag <varname>VALGRIND_MEMPOOL_METAPOOL</varname>
2433 using <varname>VALGRIND_MEMPOOL_ALLOC</varname> will be used
2435 blocks using <varname>VALGRIND_MALLOCLIKE_BLOCK</varname>.
2438 by <varname>VALGRIND_MEMPOOL_ALLOC</varname>. The second
2440 using <varname>VALGRIND_MALLOCLIKE_BLOCK</varname>. Note
2444 the <varname>VALGRIND_MEMPOOL_METAPOOL</varname> flag for
2452 <varname>VALGRIND_MEMPOOL_AUTO_FREE</varname>. Such a meta
2454 flag <varname>VALGRIND_MEMPOOL_AUTO_FREE</varname>, which
2456 the <varname>VALGRIND_MEMPOOL_METAPOOL</varname>. For an
2457 'auto free' pool, <varname>VALGRIND_MEMPOOL_FREE</varname>
2460 with <varname>VALGRIND_MEMPOOL_FREE</varname>. In other
2461 words, calling <varname>VALGRIND_MEMPOOL_FREE</varname> will
2463 to <varname>VALGRIND_FREELIKE_BLOCK</varname> for all the
2466 the <varname>VALGRIND_MEMPOOL_AUTO_FREE</varname> flag
2468 <varname>VALGRIND_MEMPOOL_METAPOOL</varname> flag.
2475 <para><varname>VALGRIND_DESTROY_MEMPOOL(pool)</varname>:
2485 <para><varname>VALGRIND_MEMPOOL_ALLOC(pool, addr, size)</varname>:
2486 This request informs Memcheck that a <varname>size</varname>-byte chunk
2487 has been allocated at <varname>addr</varname>, and associates the chunk with the
2489 <varname>pool</varname>. If the pool was created with nonzero
2490 <varname>rzB</varname> redzones, Memcheck will mark the
2491 <varname>rzB</varname> bytes before and after the chunk as NOACCESS. If
2492 the pool was created with the <varname>is_zeroed</varname> argument set,
2499 <para><varname>VALGRIND_MEMPOOL_FREE(pool, addr)</varname>:
2500 This request informs Memcheck that the chunk at <varname>addr</varname>
2502 associated with <varname>addr</varname> as NOACCESS, and delete its
2508 <para><varname>VALGRIND_MEMPOOL_TRIM(pool, addr, size)</varname>:
2509 This request trims the chunks associated with <varname>pool</varname>.
2511 <varname>pool</varname>. Trimming is formally defined as:</para>
2515 <varname>addr..(addr+size-1)</varname> are preserved.</para>
2519 <varname>addr..(addr+size-1)</varname> are discarded, as though
2520 <varname>VALGRIND_MEMPOOL_FREE</varname> was called on them. </para>
2524 <varname>addr..(addr+size-1)</varname>; areas outside the
2527 <varname>VALGRIND_MEMPOOL_FREE</varname>.</para>
2536 <para><varname>VALGRIND_MOVE_MEMPOOL(poolA, poolB)</varname>: This
2538 address <varname>poolA</varname> has moved to anchor address
2539 <varname>poolB</varname>. This is a rare request, typically only needed
2546 <varname>VALGRIND_MEMPOOL_CHANGE(pool, addrA, addrB,
2547 size)</varname>: This request informs Memcheck that the chunk
2548 previously allocated at address <varname>addrA</varname> within
2549 <varname>pool</varname> has been moved and/or resized, and should be
2550 changed to cover the region <varname>addrB..(addrB+size-1)</varname>. This
2560 <para><varname>VALGRIND_MEMPOOL_EXISTS(pool)</varname>:
2562 tracking a mempool at anchor address <varname>pool</varname>. It
