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" href="vg_basic.css" type="text/css"> 6<meta name="generator" content="DocBook XSL Stylesheets V1.75.2"> 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" title="Valgrind Frequently Asked Questions"> 21<div class="titlepage"> 22<div><div><h2 class="title"> 23<a name="faq"></a>Valgrind Frequently Asked Questions</h2></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 world "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->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="id511937"></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->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" 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" 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 won't work as well, because they won't be able to replace 543 certain functions, such as <code class="function">malloc</code>, with their own 544 versions. A key indicator of this is if Memcheck says: 545</p> 546<pre class="programlisting"> 547All heap blocks were freed -- no leaks are possible 548</pre> 549<p> 550 when you know your program calls <code class="function">malloc</code>. The 551 workaround is to avoid statically linking your program.</p> 552</td> 553</tr> 554<tr><td colspan="2">�</td></tr> 555<tr class="question"> 556<td align="left" valign="top"> 557<a name="faq.overruns"></a><a name="q-overruns"></a><b>4.6.</b> 558</td> 559<td align="left" valign="top"> 560<b>Why doesn't Memcheck find the array overruns in this 561 program?</b><pre class="programlisting"> 562int static[5]; 563 564int main(void) 565{ 566 int stack[5]; 567 568 static[5] = 0; 569 stack [5] = 0; 570 571 return 0; 572} 573</pre> 574</td> 575</tr> 576<tr class="answer"> 577<td align="left" valign="top"><a name="a-overruns"></a></td> 578<td align="left" valign="top"> 579<p>Unfortunately, Memcheck doesn't do bounds checking on static 580 or stack arrays. We'd like to, but it's just not possible to do in 581 a reasonable way that fits with how Memcheck works. Sorry.</p> 582<p>However, the experimental tool Ptrcheck can detect errors like 583 this. Run Valgrind with the <code class="option">--tool=exp-ptrcheck</code> option 584 to try it, but beware that it is not as robust as Memcheck.</p> 585</td> 586</tr> 587</table> 588<br><table width="100%" summary="Q and A Div" cellpadding="2" cellspacing="2" border="0"> 589<tr class="qandadiv"><td align="left" valign="top" colspan="2"> 590<a name="faq.misc"></a><h3 class="title"> 591<a name="faq.misc"></a>5. Miscellaneous</h3> 592</td></tr> 593<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 594 write my suppression for me?</a><br>5.2. <a href="faq.html#faq.deflost">With Memcheck's memory leak detector, what's the 595 difference between "definitely lost", "indirectly lost", "possibly 596 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, 597 because they are often reported some time after they are caused. Could 598 Memcheck record a trail of operations to better link the cause to the 599 effect? Or maybe just eagerly report any copies of uninitialised 600 memory values?</a><br>5.4. <a href="faq.html#faq.attach">Is it possible to attach Valgrind to a program that is already 601 running?</a><br> 602</td></tr> 603<tr><td colspan="2">�</td></tr> 604<tr class="question"> 605<td align="left" valign="top"> 606<a name="faq.writesupp"></a><a name="q-writesupp"></a><b>5.1.</b> 607</td> 608<td align="left" valign="top"><b>I tried writing a suppression but it didn't work. Can you 609 write my suppression for me?</b></td> 610</tr> 611<tr class="answer"> 612<td align="left" valign="top"><a name="a-writesupp"></a></td> 613<td align="left" valign="top"> 614<p>Yes! Use the <code class="option">--gen-suppressions=yes</code> feature 615 to spit out suppressions automatically for you. You can then edit 616 them if you like, eg. combining similar automatically generated 617 suppressions using wildcards like <code class="literal">'*'</code>.</p> 618<p>If you really want to write suppressions by hand, read the 619 manual carefully. Note particularly that C++ function names must be 620 mangled (that is, not demangled).</p> 621</td> 622</tr> 623<tr><td colspan="2">�</td></tr> 624<tr class="question"> 625<td align="left" valign="top"> 626<a name="faq.deflost"></a><a name="q-deflost"></a><b>5.2.</b> 627</td> 628<td align="left" valign="top"><b>With Memcheck's memory leak detector, what's the 629 difference between "definitely lost", "indirectly lost", "possibly 630 lost", "still reachable", and "suppressed"?</b></td> 631</tr> 632<tr class="answer"> 633<td align="left" valign="top"><a name="a-deflost"></a></td> 634<td align="left" valign="top"> 635<p>The details are in the Memcheck section of the user manual.</p> 636<p>In short:</p> 637<div class="itemizedlist"><ul class="itemizedlist" type="disc"> 638<li class="listitem"><p>"definitely lost" means your program is leaking memory -- 639 fix those leaks!</p></li> 640<li class="listitem"><p>"indirectly lost" means your program is leaking memory in 641 a pointer-based structure. (E.g. if the root node of a binary tree 642 is "definitely lost", all the children will be "indirectly lost".) 643 If you fix the "definitely lost" leaks, the "indirectly lost" leaks 644 should go away. 645 </p></li> 646<li class="listitem"><p>"possibly lost" means your program is leaking 647 memory, unless you're doing unusual things with pointers that could 648 cause them to point into the middle of an allocated block; see the 649 user manual for some possible causes. Use 650 <code class="option">--show-possibly-lost=no</code> if you don't want to see 651 these reports.</p></li> 652<li class="listitem"><p>"still reachable" means your program is probably ok -- it 653 didn't free some memory it could have. This is quite common and 654 often reasonable. Don't use 655 <code class="option">--show-reachable=yes</code> if you don't want to see 656 these reports.</p></li> 657<li class="listitem"><p>"suppressed" means that a leak error has been suppressed. 658 There are some suppressions in the default suppression files. 659 You can ignore suppressed errors.</p></li> 660</ul></div> 661</td> 662</tr> 663<tr><td colspan="2">�</td></tr> 664<tr class="question"> 665<td align="left" valign="top"> 666<a name="faq.undeferrors"></a><a name="q-undeferrors"></a><b>5.3.</b> 667</td> 668<td align="left" valign="top"><b>Memcheck's uninitialised value errors are hard to track down, 669 because they are often reported some time after they are caused. Could 670 Memcheck record a trail of operations to better link the cause to the 671 effect? Or maybe just eagerly report any copies of uninitialised 672 memory values?</b></td> 673</tr> 674<tr class="answer"> 675<td align="left" valign="top"><a name="a-undeferrors"></a></td> 676<td align="left" valign="top"> 677<p>Prior to version 3.4.0, the answer was "we don't know how to do it 678 without huge performance penalties". As of 3.4.0, try using the 679 <code class="option">--track-origins=yes</code> option. It will run slower than 680 usual, but will give you extra information about the origin of 681 uninitialised values.</p> 682<p>Or if you want to do it the old fashioned way, you can use the 683 client request 684 <code class="computeroutput">VALGRIND_CHECK_VALUE_IS_DEFINED</code> to help 685 track these errors down -- work backwards from the point where the 686 uninitialised error occurs, checking suspect values until you find the 687 cause. This requires editing, compiling and re-running your program 688 multiple times, which is a pain, but still easier than debugging the 689 problem without Memcheck's help.</p> 690<p>As for eager reporting of copies of uninitialised memory values, 691 this has been suggested multiple times. Unfortunately, almost all 692 programs legitimately copy uninitialised memory values around (because 693 compilers pad structs to preserve alignment) and eager checking leads to 694 hundreds of false positives. Therefore Memcheck does not support eager 695 checking at this time.</p> 696</td> 697</tr> 698<tr><td colspan="2">�</td></tr> 699<tr class="question"> 700<td align="left" valign="top"> 701<a name="faq.attach"></a><a name="q-attach"></a><b>5.4.</b> 702</td> 703<td align="left" valign="top"><b>Is it possible to attach Valgrind to a program that is already 704 running?</b></td> 705</tr> 706<tr class="answer"> 707<td align="left" valign="top"><a name="a-attach"></a></td> 708<td align="left" valign="top"> 709<p>No. The environment that Valgrind provides for running programs 710 is significantly different to that for normal programs, e.g. due to 711 different layout of memory. Therefore Valgrind has to have full control 712 from the very start.</p> 713<p>It is possible to achieve something like this by running your 714 program without any instrumentation (which involves a slow-down of about 715 5x, less than that of most tools), and then adding instrumentation once 716 you get to a point of interest. Support for this must be provided by 717 the tool, however, and Callgrind is the only tool that currently has 718 such support. See the instructions on the 719 <code class="computeroutput">callgrind_control</code> program for details. 720 </p> 721</td> 722</tr> 723</table> 724<br><table width="100%" summary="Q and A Div" cellpadding="2" cellspacing="2" border="0"> 725<tr class="qandadiv"><td align="left" valign="top" colspan="2"> 726<a name="faq.help"></a><h3 class="title"> 727<a name="faq.help"></a>6. How To Get Further Assistance</h3> 728</td></tr> 729<tr class="toc" colspan="2"><td align="left" valign="top" colspan="2"></td></tr> 730<tr class="answer"> 731<td align="left" valign="top"><a name="a-help"></a></td> 732<td align="left" valign="top"> 733<p>Read the appropriate section(s) of the 734 <a class="ulink" href="http://www.valgrind.org/docs/manual/index.html" target="_top">Valgrind Documentation</a>.</p> 735<p><a class="ulink" href="http://search.gmane.org" target="_top">Search</a> the 736 <a class="ulink" href="http://news.gmane.org/gmane.comp.debugging.valgrind" target="_top">valgrind-users</a> mailing list archives, using the group name 737 <code class="computeroutput">gmane.comp.debugging.valgrind</code>.</p> 738<p>If you think an answer in this FAQ is incomplete or inaccurate, please 739 e-mail <a class="ulink" href="mailto:valgrind@valgrind.org" target="_top">valgrind@valgrind.org</a>.</p> 740<p>If you have tried all of these things and are still 741 stuck, you can try mailing the 742 <a class="ulink" href="http://www.valgrind.org/support/mailing_lists.html" target="_top">valgrind-users mailing list</a>. 743 Note that an email has a better change of being answered usefully if it is 744 clearly written. Also remember that, despite the fact that most of the 745 community are very helpful and responsive to emailed questions, you are 746 probably requesting help from unpaid volunteers, so you have no guarantee 747 of receiving an answer.</p> 748</td> 749</tr> 750</table> 751</div> 752</div> 753<div> 754<br><table class="nav" width="100%" cellspacing="3" cellpadding="2" border="0" summary="Navigation footer"> 755<tr> 756<td rowspan="2" width="40%" align="left"> 757<a accesskey="p" href="FAQ.html"><<�Valgrind FAQ</a>�</td> 758<td width="20%" align="center"><a accesskey="u" href="FAQ.html">Up</a></td> 759<td rowspan="2" width="40%" align="right">�<a accesskey="n" href="tech-docs.html">Valgrind Technical Documentation�>></a> 760</td> 761</tr> 762<tr><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td></tr> 763</table> 764</div> 765</body> 766</html> 767
