60
60
<!-- start of xi:include in the manpage -->
61
61
<variablelist id="mc.opts.list">
63
<varlistentry id="opt.undef-value-errors" xreflabel="--undef-value-errors">
65
<option><![CDATA[--undef-value-errors=<yes|no> [default: yes] ]]></option>
68
<para>Controls whether <constant>memcheck</constant> reports
69
uses of undefined value errors. Set this to
70
<varname>no</varname> if you don't want to see undefined value
71
errors. It also has the side effect of speeding up
72
<constant>memcheck</constant> somewhat.
77
<varlistentry id="opt.track-origins" xreflabel="--track-origins">
79
<option><![CDATA[--track-origins=<yes|no> [default: no] ]]></option>
82
<para>Controls whether <constant>memcheck</constant> tracks
83
the origin of uninitialised values. By default, it does not,
84
which means that although it can tell you that an
85
uninitialised value is being used in a dangerous way, it
86
cannot tell you where the uninitialised value came from. This
87
often makes it difficult to track down the root problem.
90
to <varname>yes</varname>, <constant>memcheck</constant> keeps
91
track of the origins of all uninitialised values. Then, when
92
an uninitialised value error is
93
reported, <constant>memcheck</constant> will try to show the
94
origin of the value. An origin can be one of the following
95
four places: a heap block, a stack allocation, a client
96
request, or miscellaneous other sources (eg, a call
97
to <varname>brk</varname>).
99
<para>For uninitialised values originating from a heap
100
block, <constant>memcheck</constant> shows where the block was
101
allocated. For uninitialised values originating from a stack
102
allocation, <constant>memcheck</constant> can tell you which
103
function allocated the value, but no more than that -- typically
104
it shows you the source location of the opening brace of the
105
function. So you should carefully check that all of the
106
function's local variables are initialised properly.
108
<para>Performance overhead: origin tracking is expensive. It
109
halves <constant>memcheck</constant>'s speed and increases
110
memory use by a minimum of 100MB, and possibly more.
111
Nevertheless it can drastically reduce the effort required to
112
identify the root cause of uninitialised value errors, and so
113
is often a programmer productivity win, despite running
116
<para>Accuracy: <constant>memcheck</constant> tracks origins
117
quite accurately. To avoid very large space and time
118
overheads, some approximations are made. It is possible,
119
although unlikely, that
120
<constant>memcheck</constant> will report an incorrect origin,
121
or not be able to identify any origin.
123
<para>Note that the combination
124
<option>--track-origins=yes</option>
125
and <option>--undef-value-errors=no</option> is
126
nonsensical. <constant>memcheck</constant> checks for and
127
rejects this combination at startup.
129
<para>Origin tracking is a new feature, introduced in Valgrind
63
135
<varlistentry id="opt.leak-check" xreflabel="--leak-check">
65
137
<option><![CDATA[--leak-check=<no|summary|yes|full> [default: summary] ]]></option>
196
<varlistentry id="opt.undef-value-errors" xreflabel="--undef-value-errors">
198
<option><![CDATA[--undef-value-errors=<yes|no> [default: yes] ]]></option>
201
<para>Controls whether <constant>memcheck</constant> detects
202
dangerous uses of undefined value errors. Set this to
203
<varname>no</varname> if you don't like seeing undefined value
204
errors; it also has the side effect of speeding
205
<constant>memcheck</constant> up somewhat.
210
268
<varlistentry id="opt.malloc-fill" xreflabel="--malloc-fill">
212
270
<option><![CDATA[--malloc-fill=<hexnumber> ]]></option>
added
removed
memcheck/docs/mc-manual.xml
