Elliott Hughes | a0664b9 | 2017-04-18 17:46:52 -0700 | [diff] [blame] | 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"> |
Elliott Hughes | ed39800 | 2017-06-21 14:41:24 -0700 | [diff] [blame^] | 6 | <meta name="generator" content="DocBook XSL Stylesheets V1.79.1"> |
Elliott Hughes | a0664b9 | 2017-04-18 17:46:52 -0700 | [diff] [blame] | 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->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"> |
Elliott Hughes | ed39800 | 2017-06-21 14:41:24 -0700 | [diff] [blame^] | 190 | <a name="faq.glibc_devel"></a><a name="idm140394923880656"></a><b>2.2.</b> |
Elliott Hughes | a0664b9 | 2017-04-18 17:46:52 -0700 | [diff] [blame] | 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 |
| 195 | collect2: 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" 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"> |
| 419 | Invalid 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"> |
| 427 | Invalid 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"> |
| 435 | Invalid 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"> |
| 445 | Invalid 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"> |
| 454 | 84 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"> |
| 537 | valgrind-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"> |
| 549 | All 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"> |
| 572 | int static[5]; |
| 573 | |
| 574 | int 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"><< 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 >></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> |