1<html>
2<head>
3<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
4<title>Valgrind Frequently Asked Questions</title>
5<link rel="stylesheet" type="text/css" href="vg_basic.css">
6<meta name="generator" content="DocBook XSL Stylesheets V1.79.1">
7<link rel="home" href="index.html" title="Valgrind Documentation">
8<link rel="up" href="FAQ.html" title="Valgrind FAQ">
9<link rel="prev" href="FAQ.html" title="Valgrind FAQ">
10<link rel="next" href="tech-docs.html" title="Valgrind Technical Documentation">
11</head>
12<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
13<div><table class="nav" width="100%" cellspacing="3" cellpadding="3" border="0" summary="Navigation header"><tr>
14<td width="22px" align="center" valign="middle"><a accesskey="p" href="FAQ.html"><img src="images/prev.png" width="18" height="21" border="0" alt="Prev"></a></td>
15<td width="25px" align="center" valign="middle"><a accesskey="u" href="FAQ.html"><img src="images/up.png" width="21" height="18" border="0" alt="Up"></a></td>
16<td width="31px" align="center" valign="middle"><a accesskey="h" href="index.html"><img src="images/home.png" width="27" height="20" border="0" alt="Up"></a></td>
17<th align="center" valign="middle">Valgrind FAQ</th>
18<td width="22px" align="center" valign="middle"><a accesskey="n" href="tech-docs.html"><img src="images/next.png" width="18" height="21" border="0" alt="Next"></a></td>
19</tr></table></div>
20<div class="article">
21<div class="titlepage">
22<div><div><h1 class="title">
23<a name="faq"></a>Valgrind Frequently Asked Questions</h1></div></div>
24<hr>
25</div>
26<div class="qandaset">
27<dl>
28<dt>1.  <a href="faq.html#faq.background">Background</a>
29</dt>
30<dd>1.1. <a href="faq.html#faq.pronounce">How do you pronounce "Valgrind"?</a>
31</dd>
32<dd>1.2. <a href="faq.html#faq.whence">Where does the name "Valgrind" come from?</a>
33</dd>
34</dl>
35<dl>
36<dt>2.  <a href="faq.html#faq.installing">Compiling, installing and configuring</a>
37</dt>
38<dd>2.1. <a href="faq.html#faq.make_dies">When building Valgrind, 'make' dies partway with
39  an assertion failure, something like this:</a>
40</dd>
41<dd>2.2. <a href="faq.html#faq.glibc_devel">When building Valgrind, 'make' fails with this:</a>
42</dd>
43</dl>
44<dl>
45<dt>3.  <a href="faq.html#faq.abort">Valgrind aborts unexpectedly</a>
46</dt>
47<dd>3.1. <a href="faq.html#faq.exit_errors">Programs run OK on Valgrind, but at exit produce a bunch of
48    errors involving __libc_freeres and then die
49    with a segmentation fault.</a>
50</dd>
51<dd>3.2. <a href="faq.html#faq.bugdeath">My (buggy) program dies like this:</a>
52</dd>
53<dd>3.3. <a href="faq.html#faq.msgdeath">My program dies, printing a message like this along the
54    way:</a>
55</dd>
56<dd>3.4. <a href="faq.html#faq.java">I tried running a Java program (or another program that uses a
57    just-in-time compiler) under Valgrind but something went wrong.
58    Does Valgrind handle such programs?</a>
59</dd>
60</dl>
61<dl>
62<dt>4.  <a href="faq.html#faq.unexpected">Valgrind behaves unexpectedly</a>
63</dt>
64<dd>4.1. <a href="faq.html#faq.reports">My program uses the C++ STL and string classes.  Valgrind
65    reports 'still reachable' memory leaks involving these classes at
66    the exit of the program, but there should be none.</a>
67</dd>
68<dd>4.2. <a href="faq.html#faq.unhelpful">The stack traces given by Memcheck (or another tool) aren't
69    helpful.  How can I improve them?</a>
70</dd>
71<dd>4.3. <a href="faq.html#faq.aliases">The stack traces given by Memcheck (or another tool) seem to
72    have the wrong function name in them.  What's happening?</a>
73</dd>
74<dd>4.4. <a href="faq.html#faq.crashes">My program crashes normally, but doesn't under Valgrind, or vice
75    versa.  What's happening?</a>
76</dd>
77<dd>4.5. <a href="faq.html#faq.hiddenbug"> Memcheck doesn't report any errors and I know my program has
78    errors.</a>
79</dd>
80<dd>4.6. <a href="faq.html#faq.overruns">Why doesn't Memcheck find the array overruns in this
81    program?</a>
82</dd>
83</dl>
84<dl>
85<dt>5.  <a href="faq.html#faq.misc">Miscellaneous</a>
86</dt>
87<dd>5.1. <a href="faq.html#faq.writesupp">I tried writing a suppression but it didn't work.  Can you
88    write my suppression for me?</a>
89</dd>
90<dd>5.2. <a href="faq.html#faq.deflost">With Memcheck's memory leak detector, what's the
91    difference between "definitely lost", "indirectly lost", "possibly
92    lost", "still reachable", and "suppressed"?</a>
93</dd>
94<dd>5.3. <a href="faq.html#faq.undeferrors">Memcheck's uninitialised value errors are hard to track down,
95    because they are often reported some time after they are caused.  Could
96    Memcheck record a trail of operations to better link the cause to the
97    effect?  Or maybe just eagerly report any copies of uninitialised
98    memory values?</a>
99</dd>
100<dd>5.4. <a href="faq.html#faq.attach">Is it possible to attach Valgrind to a program that is already
101    running?</a>
102</dd>
103</dl>
104<dl><dt>6.  <a href="faq.html#faq.help">How To Get Further Assistance</a>
105</dt></dl>
106<br><table width="100%" summary="Q and A Div" cellpadding="2" cellspacing="2" border="0">
107<tr class="qandadiv"><td align="left" valign="top" colspan="2">
108<a name="faq.background"></a><h3 class="title">
109<a name="faq.background"></a>1. Background</h3>
110</td></tr>
111<tr class="toc" colspan="2"><td align="left" valign="top" colspan="2">1.1. <a href="faq.html#faq.pronounce">How do you pronounce "Valgrind"?</a><br>1.2. <a href="faq.html#faq.whence">Where does the name "Valgrind" come from?</a><br>
112</td></tr>
113<tr><td colspan="2">�</td></tr>
114<tr class="question">
115<td align="left" valign="top">
116<a name="faq.pronounce"></a><a name="q-pronounce"></a><b>1.1.</b>
117</td>
118<td align="left" valign="top"><b>How do you pronounce "Valgrind"?</b></td>
119</tr>
120<tr class="answer">
121<td align="left" valign="top"><a name="a-pronounce"></a></td>
122<td align="left" valign="top">
123<p>The "Val" as in the word "value".  The "grind" is pronounced
124  with a short 'i' -- ie. "grinned" (rhymes with "tinned") rather than
125  "grined" (rhymes with "find").</p>
126<p>Don't feel bad: almost
127  everyone gets it wrong at first.</p>
128</td>
129</tr>
130<tr><td colspan="2">�</td></tr>
131<tr class="question">
132<td align="left" valign="top">
133<a name="faq.whence"></a><a name="q-whence"></a><b>1.2.</b>
134</td>
135<td align="left" valign="top"><b>Where does the name "Valgrind" come from?</b></td>
136</tr>
137<tr class="answer">
138<td align="left" valign="top"><a name="a-whence"></a></td>
139<td align="left" valign="top">
140<p>From Nordic mythology.  Originally (before release) the project
141  was named Heimdall, after the watchman of the Nordic gods.  He could
142  "see a hundred miles by day or night, hear the grass growing, see the
143  wool growing on a sheep's back", etc.  This would have been a great
144  name, but it was already taken by a security package "Heimdal".</p>
145<p>Keeping with the Nordic theme, Valgrind was chosen.  Valgrind is
146  the name of the main entrance to Valhalla (the Hall of the Chosen
147  Slain in Asgard).  Over this entrance there resides a wolf and over it
148  there is the head of a boar and on it perches a huge eagle, whose eyes
149  can see to the far regions of the nine worlds.  Only those judged
150  worthy by the guardians are allowed to pass through Valgrind.  All
151  others are refused entrance.</p>
152<p>It's not short for "value grinder", although that's not a bad
153  guess.</p>
154</td>
155</tr>
156</table>
157<br><table width="100%" summary="Q and A Div" cellpadding="2" cellspacing="2" border="0">
158<tr class="qandadiv"><td align="left" valign="top" colspan="2">
159<a name="faq.installing"></a><h3 class="title">
160<a name="faq.installing"></a>2. Compiling, installing and configuring</h3>
161</td></tr>
162<tr class="toc" colspan="2"><td align="left" valign="top" colspan="2">2.1. <a href="faq.html#faq.make_dies">When building Valgrind, 'make' dies partway with
163  an assertion failure, something like this:</a><br>2.2. <a href="faq.html#faq.glibc_devel">When building Valgrind, 'make' fails with this:</a><br>
164</td></tr>
165<tr><td colspan="2">�</td></tr>
166<tr class="question">
167<td align="left" valign="top">
168<a name="faq.make_dies"></a><a name="q-make_dies"></a><b>2.1.</b>
169</td>
170<td align="left" valign="top">
171<b>When building Valgrind, 'make' dies partway with
172  an assertion failure, something like this:</b><pre class="screen">
173% make: expand.c:489: allocated_variable_append:
174        Assertion 'current_variable_set_list-&gt;next != 0' failed.
175</pre>
176</td>
177</tr>
178<tr class="answer">
179<td align="left" valign="top"><a name="a-make_dies"></a></td>
180<td align="left" valign="top"><p>It's probably a bug in 'make'.  Some, but not all, instances of
181  version 3.79.1 have this bug, see
182  <a class="ulink" href="http://www.mail-archive.com/bug-make@gnu.org/msg01658.html" target="_top">this</a>.
183  Try upgrading to a more recent version of 'make'.  Alternatively, we have
184  heard that unsetting the CFLAGS environment variable avoids the
185  problem.</p></td>
186</tr>
187<tr><td colspan="2">�</td></tr>
188<tr class="question">
189<td align="left" valign="top">
190<a name="faq.glibc_devel"></a><a name="idm140394923880656"></a><b>2.2.</b>
191</td>
192<td align="left" valign="top">
193<b>When building Valgrind, 'make' fails with this:</b><pre class="screen">
194/usr/bin/ld: cannot find -lc
195collect2: ld returned 1 exit status
196</pre>
197</td>
198</tr>
199<tr class="answer">
200<td align="left" valign="top"></td>
201<td align="left" valign="top"><p>You need to install the glibc-static-devel package.</p></td>
202</tr>
203</table>
204<br><table width="100%" summary="Q and A Div" cellpadding="2" cellspacing="2" border="0">
205<tr class="qandadiv"><td align="left" valign="top" colspan="2">
206<a name="faq.abort"></a><h3 class="title">
207<a name="faq.abort"></a>3. Valgrind aborts unexpectedly</h3>
208</td></tr>
209<tr class="toc" colspan="2"><td align="left" valign="top" colspan="2">3.1. <a href="faq.html#faq.exit_errors">Programs run OK on Valgrind, but at exit produce a bunch of
210    errors involving __libc_freeres and then die
211    with a segmentation fault.</a><br>3.2. <a href="faq.html#faq.bugdeath">My (buggy) program dies like this:</a><br>3.3. <a href="faq.html#faq.msgdeath">My program dies, printing a message like this along the
212    way:</a><br>3.4. <a href="faq.html#faq.java">I tried running a Java program (or another program that uses a
213    just-in-time compiler) under Valgrind but something went wrong.
214    Does Valgrind handle such programs?</a><br>
215</td></tr>
216<tr><td colspan="2">�</td></tr>
217<tr class="question">
218<td align="left" valign="top">
219<a name="faq.exit_errors"></a><a name="q-exit_errors"></a><b>3.1.</b>
220</td>
221<td align="left" valign="top"><b>Programs run OK on Valgrind, but at exit produce a bunch of
222    errors involving <code class="literal">__libc_freeres</code> and then die
223    with a segmentation fault.</b></td>
224</tr>
225<tr class="answer">
226<td align="left" valign="top"><a name="a-exit_errors"></a></td>
227<td align="left" valign="top">
228<p>When the program exits, Valgrind runs the procedure
229    <code class="function">__libc_freeres</code> in glibc.  This is a hook for
230    memory debuggers, so they can ask glibc to free up any memory it has
231    used.  Doing that is needed to ensure that Valgrind doesn't
232    incorrectly report space leaks in glibc.</p>
233<p>The problem is that running <code class="literal">__libc_freeres</code> in
234    older glibc versions causes this crash.</p>
235<p>Workaround for 1.1.X and later versions of Valgrind: use the
236    <code class="option">--run-libc-freeres=no</code> option.  You may then get space
237    leak reports for glibc allocations (please don't report these to
238    the glibc people, since they are not real leaks), but at least the
239    program runs.</p>
240</td>
241</tr>
242<tr><td colspan="2">�</td></tr>
243<tr class="question">
244<td align="left" valign="top">
245<a name="faq.bugdeath"></a><a name="q-bugdeath"></a><b>3.2.</b>
246</td>
247<td align="left" valign="top">
248<b>My (buggy) program dies like this:</b><pre class="screen">valgrind: m_mallocfree.c:248 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.</pre>
249<b>or like this:</b><pre class="screen">valgrind: m_mallocfree.c:442 (mk_inuse_bszB): Assertion 'bszB != 0' failed.</pre>
250<b>or otherwise aborts or crashes in m_mallocfree.c.</b>
251</td>
252</tr>
253<tr class="answer">
254<td align="left" valign="top"><a name="a-bugdeath"></a></td>
255<td align="left" valign="top"><p>If Memcheck (the memory checker) shows any invalid reads,
256    invalid writes or invalid frees in your program, the above may
257    happen.  Reason is that your program may trash Valgrind's low-level
258    memory manager, which then dies with the above assertion, or
259    something similar.  The cure is to fix your program so that it
260    doesn't do any illegal memory accesses.  The above failure will
261    hopefully go away after that.</p></td>
262</tr>
263<tr><td colspan="2">�</td></tr>
264<tr class="question">
265<td align="left" valign="top">
266<a name="faq.msgdeath"></a><a name="q-msgdeath"></a><b>3.3.</b>
267</td>
268<td align="left" valign="top">
269<b>My program dies, printing a message like this along the
270    way:</b><pre class="screen">vex x86-&gt;IR: unhandled instruction bytes: 0x66 0xF 0x2E 0x5</pre>
271</td>
272</tr>
273<tr class="answer">
274<td align="left" valign="top"><a name="a-msgdeath"></a></td>
275<td align="left" valign="top">
276<p>One possibility is that your program has a bug and erroneously
277    jumps to a non-code address, in which case you'll get a SIGILL signal.
278    Memcheck may issue a warning just before this happens, but it might not
279    if the jump happens to land in addressable memory.</p>
280<p>Another possibility is that Valgrind does not handle the
281    instruction.  If you are using an older Valgrind, a newer version might
282    handle the instruction.  However, all instruction sets have some
283    obscure, rarely used instructions.  Also, on amd64 there are an almost
284    limitless number of combinations of redundant instruction prefixes, many
285    of them undocumented but accepted by CPUs.  So Valgrind will still have
286    decoding failures from time to time.  If this happens, please file a bug
287    report.</p>
288</td>
289</tr>
290<tr><td colspan="2">�</td></tr>
291<tr class="question">
292<td align="left" valign="top">
293<a name="faq.java"></a><a name="q-java"></a><b>3.4.</b>
294</td>
295<td align="left" valign="top"><b>I tried running a Java program (or another program that uses a
296    just-in-time compiler) under Valgrind but something went wrong.
297    Does Valgrind handle such programs?</b></td>
298</tr>
299<tr class="answer">
300<td align="left" valign="top"><a name="a-java"></a></td>
301<td align="left" valign="top">
302<p>Valgrind can handle dynamically generated code, so long as
303    none of the generated code is later overwritten by other generated
304    code.  If this happens, though, things will go wrong as Valgrind
305    will continue running its translations of the old code (this is true
306    on x86 and amd64, on PowerPC there are explicit cache flush
307    instructions which Valgrind detects and honours).
308    You should try running with
309    <code class="option">--smc-check=all</code> in this case.  Valgrind will run
310    much more slowly, but should detect the use of the out-of-date
311    code.</p>
312<p>Alternatively, if you have the source code to the JIT compiler
313    you can insert calls to the
314    <code class="computeroutput">VALGRIND_DISCARD_TRANSLATIONS</code>
315    client request to mark out-of-date code, saving you from using
316    <code class="option">--smc-check=all</code>.</p>
317<p>Apart from this, in theory Valgrind can run any Java program
318    just fine, even those that use JNI and are partially implemented in
319    other languages like C and C++.  In practice, Java implementations
320    tend to do nasty things that most programs do not, and Valgrind
321    sometimes falls over these corner cases.</p>
322<p>If your Java programs do not run under Valgrind, even with
323    <code class="option">--smc-check=all</code>, please file a bug report and
324    hopefully we'll be able to fix the problem.</p>
325</td>
326</tr>
327</table>
328<br><table width="100%" summary="Q and A Div" cellpadding="2" cellspacing="2" border="0">
329<tr class="qandadiv"><td align="left" valign="top" colspan="2">
330<a name="faq.unexpected"></a><h3 class="title">
331<a name="faq.unexpected"></a>4. Valgrind behaves unexpectedly</h3>
332</td></tr>
333<tr class="toc" colspan="2"><td align="left" valign="top" colspan="2">4.1. <a href="faq.html#faq.reports">My program uses the C++ STL and string classes.  Valgrind
334    reports 'still reachable' memory leaks involving these classes at
335    the exit of the program, but there should be none.</a><br>4.2. <a href="faq.html#faq.unhelpful">The stack traces given by Memcheck (or another tool) aren't
336    helpful.  How can I improve them?</a><br>4.3. <a href="faq.html#faq.aliases">The stack traces given by Memcheck (or another tool) seem to
337    have the wrong function name in them.  What's happening?</a><br>4.4. <a href="faq.html#faq.crashes">My program crashes normally, but doesn't under Valgrind, or vice
338    versa.  What's happening?</a><br>4.5. <a href="faq.html#faq.hiddenbug"> Memcheck doesn't report any errors and I know my program has
339    errors.</a><br>4.6. <a href="faq.html#faq.overruns">Why doesn't Memcheck find the array overruns in this
340    program?</a><br>
341</td></tr>
342<tr><td colspan="2">�</td></tr>
343<tr class="question">
344<td align="left" valign="top">
345<a name="faq.reports"></a><a name="q-reports"></a><b>4.1.</b>
346</td>
347<td align="left" valign="top"><b>My program uses the C++ STL and string classes.  Valgrind
348    reports 'still reachable' memory leaks involving these classes at
349    the exit of the program, but there should be none.</b></td>
350</tr>
351<tr class="answer">
352<td align="left" valign="top"><a name="a-reports"></a></td>
353<td align="left" valign="top">
354<p>First of all: relax, it's probably not a bug, but a feature.
355    Many implementations of the C++ standard libraries use their own
356    memory pool allocators.  Memory for quite a number of destructed
357    objects is not immediately freed and given back to the OS, but kept
358    in the pool(s) for later re-use.  The fact that the pools are not
359    freed at the exit of the program cause Valgrind to report this
360    memory as still reachable.  The behaviour not to free pools at the
361    exit could be called a bug of the library though.</p>
362<p>Using GCC, you can force the STL to use malloc and to free
363    memory as soon as possible by globally disabling memory caching.
364    Beware!  Doing so will probably slow down your program, sometimes
365    drastically.</p>
366<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
367<li class="listitem"><p>With GCC 2.91, 2.95, 3.0 and 3.1, compile all source using
368        the STL with <code class="literal">-D__USE_MALLOC</code>. Beware!  This was
369        removed from GCC starting with version 3.3.</p></li>
370<li class="listitem"><p>With GCC 3.2.2 and later, you should export the
371        environment variable <code class="literal">GLIBCPP_FORCE_NEW</code> before
372        running your program.</p></li>
373<li class="listitem"><p>With GCC 3.4 and later, that variable has changed name to
374        <code class="literal">GLIBCXX_FORCE_NEW</code>.</p></li>
375</ul></div>
376<p>There are other ways to disable memory pooling: using the
377    <code class="literal">malloc_alloc</code> template with your objects (not
378    portable, but should work for GCC) or even writing your own memory
379    allocators. But all this goes beyond the scope of this FAQ.  Start
380    by reading
381    <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_4_leak" target="_top">
382         http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_4_leak</a>
383    if you absolutely want to do that. But beware:
384    allocators belong to the more messy parts of the STL and
385    people went to great lengths to make the STL portable across
386    platforms. Chances are good that your solution will work on your
387    platform, but not on others.</p>
388</td>
389</tr>
390<tr><td colspan="2">�</td></tr>
391<tr class="question">
392<td align="left" valign="top">
393<a name="faq.unhelpful"></a><a name="q-unhelpful"></a><b>4.2.</b>
394</td>
395<td align="left" valign="top"><b>The stack traces given by Memcheck (or another tool) aren't
396    helpful.  How can I improve them?</b></td>
397</tr>
398<tr class="answer">
399<td align="left" valign="top"><a name="a-unhelpful"></a></td>
400<td align="left" valign="top">
401<p>If they're not long enough, use <code class="option">--num-callers</code>
402    to make them longer.</p>
403<p>If they're not detailed enough, make sure you are compiling
404    with <code class="option">-g</code> to add debug information.  And don't strip
405    symbol tables (programs should be unstripped unless you run 'strip'
406    on them; some libraries ship stripped).</p>
407<p>Also, for leak reports involving shared objects, if the shared
408    object is unloaded before the program terminates, Valgrind will
409    discard the debug information and the error message will be full of
410    <code class="literal">???</code> entries.  The workaround here is to avoid
411    calling <code class="function">dlclose</code> on these shared objects.</p>
412<p>Also, <code class="option">-fomit-frame-pointer</code> and
413    <code class="option">-fstack-check</code> can make stack traces worse.</p>
414<p>Some example sub-traces:</p>
415<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
416<li class="listitem">
417<p>With debug information and unstripped (best):</p>
418<pre class="programlisting">
419Invalid write of size 1
420   at 0x80483BF: really (malloc1.c:20)
421   by 0x8048370: main (malloc1.c:9)
422</pre>
423</li>
424<li class="listitem">
425<p>With no debug information, unstripped:</p>
426<pre class="programlisting">
427Invalid write of size 1
428   at 0x80483BF: really (in /auto/homes/njn25/grind/head5/a.out)
429   by 0x8048370: main (in /auto/homes/njn25/grind/head5/a.out)
430</pre>
431</li>
432<li class="listitem">
433<p>With no debug information, stripped:</p>
434<pre class="programlisting">
435Invalid write of size 1
436   at 0x80483BF: (within /auto/homes/njn25/grind/head5/a.out)
437   by 0x8048370: (within /auto/homes/njn25/grind/head5/a.out)
438   by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)
439   by 0x80482CC: (within /auto/homes/njn25/grind/head5/a.out)
440</pre>
441</li>
442<li class="listitem">
443<p>With debug information and -fomit-frame-pointer:</p>
444<pre class="programlisting">
445Invalid write of size 1
446   at 0x80483C4: really (malloc1.c:20)
447   by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)
448   by 0x80482CC: ??? (start.S:81)
449</pre>
450</li>
451<li class="listitem">
452<p>A leak error message involving an unloaded shared object:</p>
453<pre class="programlisting">
45484 bytes in 1 blocks are possibly lost in loss record 488 of 713
455   at 0x1B9036DA: operator new(unsigned) (vg_replace_malloc.c:132)
456   by 0x1DB63EEB: ???
457   by 0x1DB4B800: ???
458   by 0x1D65E007: ???
459   by 0x8049EE6: main (main.cpp:24)
460</pre>
461</li>
462</ul></div>
463</td>
464</tr>
465<tr><td colspan="2">�</td></tr>
466<tr class="question">
467<td align="left" valign="top">
468<a name="faq.aliases"></a><a name="q-aliases"></a><b>4.3.</b>
469</td>
470<td align="left" valign="top"><b>The stack traces given by Memcheck (or another tool) seem to
471    have the wrong function name in them.  What's happening?</b></td>
472</tr>
473<tr class="answer">
474<td align="left" valign="top"><a name="a-aliases"></a></td>
475<td align="left" valign="top"><p>Occasionally Valgrind stack traces get the wrong function
476    names.  This is caused by glibc using aliases to effectively give
477    one function two names.  Most of the time Valgrind chooses a
478    suitable name, but very occasionally it gets it wrong.  Examples we know
479    of are printing <code class="function">bcmp</code> instead of
480    <code class="function">memcmp</code>, <code class="function">index</code> instead of
481    <code class="function">strchr</code>, and <code class="function">rindex</code> instead of
482    <code class="function">strrchr</code>.</p></td>
483</tr>
484<tr><td colspan="2">�</td></tr>
485<tr class="question">
486<td align="left" valign="top">
487<a name="faq.crashes"></a><a name="q-crashes"></a><b>4.4.</b>
488</td>
489<td align="left" valign="top"><b>My program crashes normally, but doesn't under Valgrind, or vice
490    versa.  What's happening?</b></td>
491</tr>
492<tr class="answer">
493<td align="left" valign="top"><a name="a-crashes"></a></td>
494<td align="left" valign="top">
495<p>When a program runs under Valgrind, its environment is slightly
496    different to when it runs natively.  For example, the memory layout is
497    different, and the way that threads are scheduled is different.</p>
498<p>Most of the time this doesn't make any difference, but it can,
499    particularly if your program is buggy.  For example, if your program
500    crashes because it erroneously accesses memory that is unaddressable,
501    it's possible that this memory will not be unaddressable when run under
502    Valgrind.  Alternatively, if your program has data races, these may not
503    manifest under Valgrind.</p>
504<p>There isn't anything you can do to change this, it's just the
505    nature of the way Valgrind works that it cannot exactly replicate a
506    native execution environment.  In the case where your program crashes
507    due to a memory error when run natively but not when run under Valgrind,
508    in most cases Memcheck should identify the bad memory operation.</p>
509</td>
510</tr>
511<tr><td colspan="2">�</td></tr>
512<tr class="question">
513<td align="left" valign="top">
514<a name="faq.hiddenbug"></a><a name="q-hiddenbug"></a><b>4.5.</b>
515</td>
516<td align="left" valign="top"><b> Memcheck doesn't report any errors and I know my program has
517    errors.</b></td>
518</tr>
519<tr class="answer">
520<td align="left" valign="top"><a name="a-hiddenbug"></a></td>
521<td align="left" valign="top">
522<p>There are two possible causes of this.</p>
523<p>First, by default, Valgrind only traces the top-level process.
524    So if your program spawns children, they won't be traced by Valgrind
525    by default.  Also, if your program is started by a shell script,
526    Perl script, or something similar, Valgrind will trace the shell, or
527    the Perl interpreter, or equivalent.</p>
528<p>To trace child processes, use the
529    <code class="option">--trace-children=yes</code> option.</p>
530<p>If you are tracing large trees of processes, it can be less
531    disruptive to have the output sent over the network.  Give Valgrind
532    the option <code class="option">--log-socket=127.0.0.1:12345</code> (if you want
533    logging output sent to port <code class="literal">12345</code> on
534    <code class="literal">localhost</code>).  You can use the valgrind-listener
535    program to listen on that port:</p>
536<pre class="programlisting">
537valgrind-listener 12345
538</pre>
539<p>Obviously you have to start the listener process first.  See
540    the manual for more details.</p>
541<p>Second, if your program is statically linked, most Valgrind
542    tools will only work well if they are able to replace certain
543    functions, such as <code class="function">malloc</code>, with their own
544    versions.  By default, statically linked <code class="function">malloc
545    functions</code> are not replaced. A key indicator of this is
546    if Memcheck says:
547</p>
548<pre class="programlisting">
549All heap blocks were freed -- no leaks are possible
550</pre>
551<p>
552    when you know your program calls <code class="function">malloc</code>.  The
553    workaround is to use the option
554    <code class="option">--soname-synonyms=somalloc=NONE</code>
555    or to avoid statically linking your program.</p>
556<p>There will also be no replacement if you use an alternative
557    <code class="function">malloc library</code> such as tcmalloc, jemalloc,
558    ...  In such a case, the
559    option <code class="option">--soname-synonyms=somalloc=zzzz</code> (where
560    zzzz is the soname of the alternative malloc library) will allow
561    Valgrind to replace the functions.</p>
562</td>
563</tr>
564<tr><td colspan="2">�</td></tr>
565<tr class="question">
566<td align="left" valign="top">
567<a name="faq.overruns"></a><a name="q-overruns"></a><b>4.6.</b>
568</td>
569<td align="left" valign="top">
570<b>Why doesn't Memcheck find the array overruns in this
571    program?</b><pre class="programlisting">
572int static[5];
573
574int main(void)
575{
576  int stack[5];
577
578  static[5] = 0;
579  stack [5] = 0;
580
581  return 0;
582}
583</pre>
584</td>
585</tr>
586<tr class="answer">
587<td align="left" valign="top"><a name="a-overruns"></a></td>
588<td align="left" valign="top">
589<p>Unfortunately, Memcheck doesn't do bounds checking on global
590    or stack arrays.  We'd like to, but it's just not possible to do in
591    a reasonable way that fits with how Memcheck works.  Sorry.</p>
592<p>However, the experimental tool SGcheck can detect errors like
593    this.  Run Valgrind with the <code class="option">--tool=exp-sgcheck</code> option
594    to try it, but be aware that it is not as robust as Memcheck.</p>
595</td>
596</tr>
597</table>
598<br><table width="100%" summary="Q and A Div" cellpadding="2" cellspacing="2" border="0">
599<tr class="qandadiv"><td align="left" valign="top" colspan="2">
600<a name="faq.misc"></a><h3 class="title">
601<a name="faq.misc"></a>5. Miscellaneous</h3>
602</td></tr>
603<tr class="toc" colspan="2"><td align="left" valign="top" colspan="2">5.1. <a href="faq.html#faq.writesupp">I tried writing a suppression but it didn't work.  Can you
604    write my suppression for me?</a><br>5.2. <a href="faq.html#faq.deflost">With Memcheck's memory leak detector, what's the
605    difference between "definitely lost", "indirectly lost", "possibly
606    lost", "still reachable", and "suppressed"?</a><br>5.3. <a href="faq.html#faq.undeferrors">Memcheck's uninitialised value errors are hard to track down,
607    because they are often reported some time after they are caused.  Could
608    Memcheck record a trail of operations to better link the cause to the
609    effect?  Or maybe just eagerly report any copies of uninitialised
610    memory values?</a><br>5.4. <a href="faq.html#faq.attach">Is it possible to attach Valgrind to a program that is already
611    running?</a><br>
612</td></tr>
613<tr><td colspan="2">�</td></tr>
614<tr class="question">
615<td align="left" valign="top">
616<a name="faq.writesupp"></a><a name="q-writesupp"></a><b>5.1.</b>
617</td>
618<td align="left" valign="top"><b>I tried writing a suppression but it didn't work.  Can you
619    write my suppression for me?</b></td>
620</tr>
621<tr class="answer">
622<td align="left" valign="top"><a name="a-writesupp"></a></td>
623<td align="left" valign="top">
624<p>Yes!  Use the <code class="option">--gen-suppressions=yes</code> feature
625    to spit out suppressions automatically for you.  You can then edit
626    them if you like, eg.  combining similar automatically generated
627    suppressions using wildcards like <code class="literal">'*'</code>.</p>
628<p>If you really want to write suppressions by hand, read the
629    manual carefully.  Note particularly that C++ function names must be
630    mangled (that is, not demangled).</p>
631</td>
632</tr>
633<tr><td colspan="2">�</td></tr>
634<tr class="question">
635<td align="left" valign="top">
636<a name="faq.deflost"></a><a name="q-deflost"></a><b>5.2.</b>
637</td>
638<td align="left" valign="top"><b>With Memcheck's memory leak detector, what's the
639    difference between "definitely lost", "indirectly lost", "possibly
640    lost", "still reachable", and "suppressed"?</b></td>
641</tr>
642<tr class="answer">
643<td align="left" valign="top"><a name="a-deflost"></a></td>
644<td align="left" valign="top">
645<p>The details are in the Memcheck section of the user manual.</p>
646<p>In short:</p>
647<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
648<li class="listitem"><p>"definitely lost" means your program is leaking memory --
649        fix those leaks!</p></li>
650<li class="listitem"><p>"indirectly lost" means your program is leaking memory in
651        a pointer-based structure.  (E.g. if the root node of a binary tree
652        is "definitely lost", all the children will be "indirectly lost".)
653        If you fix the "definitely lost" leaks, the "indirectly lost" leaks
654        should go away.
655        </p></li>
656<li class="listitem"><p>"possibly lost" means your program is leaking
657        memory, unless you're doing unusual things with pointers that could
658        cause them to point into the middle of an allocated block;  see the
659        user manual for some possible causes.  Use
660        <code class="option">--show-possibly-lost=no</code> if you don't want to see
661        these reports.</p></li>
662<li class="listitem"><p>"still reachable" means your program is probably ok -- it
663        didn't free some memory it could have.  This is quite common and
664        often reasonable.  Don't use
665        <code class="option">--show-reachable=yes</code> if you don't want to see
666        these reports.</p></li>
667<li class="listitem"><p>"suppressed" means that a leak error has been suppressed.
668        There are some suppressions in the default suppression files.
669        You can ignore suppressed errors.</p></li>
670</ul></div>
671</td>
672</tr>
673<tr><td colspan="2">�</td></tr>
674<tr class="question">
675<td align="left" valign="top">
676<a name="faq.undeferrors"></a><a name="q-undeferrors"></a><b>5.3.</b>
677</td>
678<td align="left" valign="top"><b>Memcheck's uninitialised value errors are hard to track down,
679    because they are often reported some time after they are caused.  Could
680    Memcheck record a trail of operations to better link the cause to the
681    effect?  Or maybe just eagerly report any copies of uninitialised
682    memory values?</b></td>
683</tr>
684<tr class="answer">
685<td align="left" valign="top"><a name="a-undeferrors"></a></td>
686<td align="left" valign="top">
687<p>Prior to version 3.4.0, the answer was "we don't know how to do it
688    without huge performance penalties".  As of 3.4.0, try using the
689    <code class="option">--track-origins=yes</code> option.  It will run slower than
690    usual, but will give you extra information about the origin of
691    uninitialised values.</p>
692<p>Or if you want to do it the old fashioned way, you can use the
693    client request
694    <code class="computeroutput">VALGRIND_CHECK_VALUE_IS_DEFINED</code> to help
695    track these errors down -- work backwards from the point where the
696    uninitialised error occurs, checking suspect values until you find the
697    cause.  This requires editing, compiling and re-running your program
698    multiple times, which is a pain, but still easier than debugging the
699    problem without Memcheck's help.</p>
700<p>As for eager reporting of copies of uninitialised memory values,
701    this has been suggested multiple times.  Unfortunately, almost all
702    programs legitimately copy uninitialised memory values around (because
703    compilers pad structs to preserve alignment) and eager checking leads to
704    hundreds of false positives.  Therefore Memcheck does not support eager
705    checking at this time.</p>
706</td>
707</tr>
708<tr><td colspan="2">�</td></tr>
709<tr class="question">
710<td align="left" valign="top">
711<a name="faq.attach"></a><a name="q-attach"></a><b>5.4.</b>
712</td>
713<td align="left" valign="top"><b>Is it possible to attach Valgrind to a program that is already
714    running?</b></td>
715</tr>
716<tr class="answer">
717<td align="left" valign="top"><a name="a-attach"></a></td>
718<td align="left" valign="top">
719<p>No.  The environment that Valgrind provides for running programs
720    is significantly different to that for normal programs, e.g. due to
721    different layout of memory.  Therefore Valgrind has to have full control
722    from the very start.</p>
723<p>It is possible to achieve something like this by running your
724    program without any instrumentation (which involves a slow-down of about
725    5x, less than that of most tools), and then adding instrumentation once
726    you get to a point of interest.  Support for this must be provided by
727    the tool, however, and Callgrind is the only tool that currently has
728    such support.  See the instructions on the
729    <code class="computeroutput">callgrind_control</code> program for details.
730    </p>
731</td>
732</tr>
733</table>
734<br><table width="100%" summary="Q and A Div" cellpadding="2" cellspacing="2" border="0">
735<tr class="qandadiv"><td align="left" valign="top" colspan="2">
736<a name="faq.help"></a><h3 class="title">
737<a name="faq.help"></a>6. How To Get Further Assistance</h3>
738</td></tr>
739<tr class="toc" colspan="2"><td align="left" valign="top" colspan="2"></td></tr>
740<tr class="answer">
741<td align="left" valign="top"><a name="a-help"></a></td>
742<td align="left" valign="top">
743<p>Read the appropriate section(s) of the
744  <a class="ulink" href="http://www.valgrind.org/docs/manual/index.html" target="_top">Valgrind Documentation</a>.</p>
745<p><a class="ulink" href="http://search.gmane.org" target="_top">Search</a> the
746  <a class="ulink" href="http://news.gmane.org/gmane.comp.debugging.valgrind" target="_top">valgrind-users</a> mailing list archives, using the group name
747  <code class="computeroutput">gmane.comp.debugging.valgrind</code>.</p>
748<p>If you think an answer in this FAQ is incomplete or inaccurate, please
749  e-mail <a class="ulink" href="mailto:valgrind@valgrind.org" target="_top">valgrind@valgrind.org</a>.</p>
750<p>If you have tried all of these things and are still
751  stuck, you can try mailing the
752  <a class="ulink" href="http://www.valgrind.org/support/mailing_lists.html" target="_top">valgrind-users mailing list</a>.
753  Note that an email has a better change of being answered usefully if it is
754  clearly written.  Also remember that, despite the fact that most of the
755  community are very helpful and responsive to emailed questions, you are
756  probably requesting help from unpaid volunteers, so you have no guarantee
757  of receiving an answer.</p>
758</td>
759</tr>
760</table>
761</div>
762</div>
763<div>
764<br><table class="nav" width="100%" cellspacing="3" cellpadding="2" border="0" summary="Navigation footer">
765<tr>
766<td rowspan="2" width="40%" align="left">
767<a accesskey="p" href="FAQ.html">&lt;&lt;�Valgrind FAQ</a>�</td>
768<td width="20%" align="center"><a accesskey="u" href="FAQ.html">Up</a></td>
769<td rowspan="2" width="40%" align="right">�<a accesskey="n" href="tech-docs.html">Valgrind Technical Documentation�&gt;&gt;</a>
770</td>
771</tr>
772<tr><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td></tr>
773</table>
774</div>
775</body>
776</html>
777