njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1 | <?xml version="1.0"?> <!-- -*- sgml -*- --> |
| 2 | <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" |
| 3 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" |
| 4 | [ <!ENTITY % vg-entities SYSTEM "vg-entities.xml"> %vg-entities; ]> |
| 5 | |
| 6 | <book id="FAQ" xreflabel="Valgrind FAQ"> |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 7 | <title>Valgrind FAQ</title> |
| 8 | <bookinfo> |
| 9 | <subtitle>Valgrind Frequently Asked Questions</subtitle> |
| 10 | <releaseinfo>August 2005</releaseinfo> |
| 11 | <author> |
| 12 | <surname> |
| 13 | <ulink url="http://www.valgrind.org/www/developers.html">Valgrind Developers</ulink> |
| 14 | </surname> |
| 15 | <affiliation><orgname> |
| 16 | <ulink url="mailto:&vg-vemail;">&vg-vemail;</ulink> |
| 17 | </orgname></affiliation> |
| 18 | </author> |
| 19 | </bookinfo> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 20 | |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 21 | <sect1 id="faq.background" xreflabel="Background"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 22 | <title>Background</title> |
| 23 | |
| 24 | <qandaset id="qset.background"> |
| 25 | |
| 26 | <qandaentry id="faq.pronounce"> |
| 27 | <question> |
| 28 | <para>How do you pronounce "Valgrind"?</para> |
| 29 | </question> |
| 30 | <answer> |
| 31 | <para>The "Val" as in the world "value". The "grind" is |
| 32 | pronounced with a short 'i' -- ie. "grinned" (rhymes with |
| 33 | "tinned") rather than "grined" (rhymes with "find").</para> |
| 34 | <para>Don't feel bad: almost everyone gets it wrong at |
| 35 | first.</para> |
| 36 | </answer> |
| 37 | </qandaentry> |
| 38 | |
| 39 | <qandaentry id="faq.whence"> |
| 40 | <question> |
| 41 | <para>Where does the name "Valgrind" come from?</para> |
| 42 | </question> |
| 43 | <answer> |
| 44 | <para>From Nordic mythology. Originally (before release) the |
| 45 | project was named Heimdall, after the watchman of the Nordic |
| 46 | gods. He could "see a hundred miles by day or night, hear the |
| 47 | grass growing, see the wool growing on a sheep's back" (etc). |
| 48 | This would have been a great name, but it was already taken by |
| 49 | a security package "Heimdal".</para> <para>Keeping with the |
| 50 | Nordic theme, Valgrind was chosen. Valgrind is the name of the |
| 51 | main entrance to Valhalla (the Hall of the Chosen Slain in |
| 52 | Asgard). Over this entrance there resides a wolf and over it |
| 53 | there is the head of a boar and on it perches a huge eagle, |
| 54 | whose eyes can see to the far regions of the nine worlds. Only |
| 55 | those judged worthy by the guardians are allowed to pass |
| 56 | through Valgrind. All others are refused entrance.</para> |
| 57 | <para>It's not short for "value grinder", although that's not a |
| 58 | bad guess.</para> |
| 59 | </answer> |
| 60 | </qandaentry> |
| 61 | |
| 62 | </qandaset> |
| 63 | |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 64 | </sect1> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 65 | |
| 66 | |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 67 | <sect1 id="faq.installing" |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 68 | xreflabel="Compiling, installing and configuring"> |
| 69 | <title>Compiling, installing and configuring</title> |
| 70 | <qandaset id="qset.installing"> |
| 71 | |
| 72 | <qandaentry id="faq.make_dies"> |
| 73 | <question> |
| 74 | <para>When I trying building Valgrind, 'make' dies partway with |
| 75 | an assertion failure, something like this: |
| 76 | <screen> |
| 77 | % make: expand.c:489: allocated_variable_append: |
| 78 | Assertion 'current_variable_set_list->next != 0' failed. |
| 79 | </screen> |
| 80 | </para> |
| 81 | </question> |
| 82 | <answer> |
| 83 | <para>It's probably a bug in 'make'. Some, but not all, |
| 84 | instances of version 3.79.1 have this bug, see |
| 85 | www.mail-archive.com/bug-make@gnu.org/msg01658.html. Try |
| 86 | upgrading to a more recent version of 'make'. Alternatively, |
| 87 | we have heard that unsetting the CFLAGS environment variable |
| 88 | avoids the problem.</para> |
| 89 | </answer> |
| 90 | </qandaentry> |
| 91 | |
| 92 | </qandaset> |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 93 | </sect1> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 94 | |
| 95 | |
| 96 | |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 97 | <sect1 id="faq.abort" |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 98 | xreflabel="Valgrind aborts unexpectedly"> |
| 99 | <title>Valgrind aborts unexpectedly</title> |
| 100 | <qandaset id="qset.abort"> |
| 101 | |
| 102 | <qandaentry id="faq.exit_errors"> |
| 103 | <question> |
| 104 | <para>Programs run OK on Valgrind, but at exit produce a bunch |
| 105 | of errors a bit like this:</para> |
| 106 | </question> |
| 107 | <answer><para> |
| 108 | <programlisting> |
| 109 | ==20755== Invalid read of size 4 |
| 110 | ==20755== at 0x40281C8A: _nl_unload_locale (loadlocale.c:238) |
| 111 | ==20755== by 0x4028179D: free_mem (findlocale.c:257) |
| 112 | ==20755== by 0x402E0962: __libc_freeres (set-freeres.c:34) |
| 113 | ==20755== by 0x40048DCC: vgPlain___libc_freeres_wrapper (vg_clientfuncs.c:585) |
| 114 | ==20755== Address 0x40CC304C is 8 bytes inside a block of size 380 free'd |
| 115 | ==20755== at 0x400484C9: free (vg_clientfuncs.c:180) |
| 116 | ==20755== by 0x40281CBA: _nl_unload_locale (loadlocale.c:246) |
| 117 | ==20755== by 0x40281218: free_mem (setlocale.c:461) |
| 118 | ==20755== by 0x402E0962: __libc_freeres (set-freeres.c:34) |
| 119 | </programlisting> |
| 120 | |
| 121 | and then die with a segmentation fault.</para> |
| 122 | <para>When the program exits, Valgrind runs the procedure |
| 123 | <literal>__libc_freeres()</literal> in glibc. This is a hook |
| 124 | for memory debuggers, so they can ask glibc to free up any |
| 125 | memory it has used. Doing that is needed to ensure that |
| 126 | Valgrind doesn't incorrectly report space leaks in glibc.</para> |
| 127 | <para>Problem is that running |
| 128 | <literal>__libc_freeres()</literal> in older glibc versions |
| 129 | causes this crash.</para> <para>WORKAROUND FOR 1.1.X and later |
| 130 | versions of Valgrind: use the |
| 131 | <literal>--run-libc-freeres=no</literal> flag. You may then get |
| 132 | space leak reports for glibc-allocations (please _don't_ report |
| 133 | these to the glibc people, since they are not real leaks), but |
| 134 | at least the program runs.</para> |
| 135 | </answer> |
| 136 | </qandaentry> |
| 137 | |
| 138 | <qandaentry id="faq.bugdeath"> |
| 139 | <question> |
| 140 | <para>My (buggy) program dies like this:</para> |
| 141 | </question> |
| 142 | <answer> |
| 143 | <screen> |
| 144 | % valgrind: vg_malloc2.c:442 (bszW_to_pszW): Assertion 'pszW >= 0' failed. |
| 145 | </screen> |
| 146 | |
| 147 | <para>If Memcheck (the memory checker) shows any invalid reads, |
| 148 | invalid writes and invalid frees in your program, the above may |
| 149 | happen. Reason is that your program may trash Valgrind's |
| 150 | low-level memory manager, which then dies with the above |
| 151 | assertion, or something like this. The cure is to fix your |
| 152 | program so that it doesn't do any illegal memory accesses. The |
| 153 | above failure will hopefully go away after that.</para> |
| 154 | </answer> |
| 155 | </qandaentry> |
| 156 | |
| 157 | <qandaentry id="faq.msgdeath"> |
| 158 | <question> |
| 159 | <para>My program dies, printing a message like this along the |
| 160 | way:</para> |
| 161 | </question> |
| 162 | <answer> |
| 163 | <screen> |
| 164 | % disInstr: unhandled instruction bytes: 0x66 0xF 0x2E 0x5 |
| 165 | </screen> |
| 166 | |
| 167 | <para>Older versions did not support some x86 instructions, |
| 168 | particularly SSE/SSE2 instructions. Try a newer Valgrind; we |
| 169 | now support almost all instructions. If it still happens with |
| 170 | newer versions, if the failing instruction is an SSE/SSE2 |
njn | d0d6473 | 2005-04-16 14:58:34 +0000 | [diff] [blame] | 171 | instruction, you might be able to recompile your program |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 172 | without it by using the flag |
| 173 | <computeroutput>-march</computeroutput> to gcc. Either way, |
| 174 | let us know and we'll try to fix it.</para> |
| 175 | |
| 176 | <para>Another possibility is that your program has a bug and |
| 177 | erroneously jumps to a non-code address, in which case you'll |
| 178 | get a SIGILL signal. Memcheck/Addrcheck may issue a warning |
| 179 | just before this happens, but they might not if the jump |
| 180 | happens to land in addressable memory.</para> |
| 181 | </answer> |
| 182 | </qandaentry> |
| 183 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 184 | </qandaset> |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 185 | </sect1> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 186 | |
| 187 | |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 188 | <sect1 id="faq.unexpected" |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 189 | xreflabel="Valgrind behaves unexpectedly"> |
| 190 | <title>Valgrind behaves unexpectedly</title> |
| 191 | <qandaset id="qset.unexpected"> |
| 192 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 193 | <qandaentry id="faq.slowthread"> |
| 194 | <question> |
| 195 | <para>My threaded server process runs unbelievably slowly on |
| 196 | Valgrind. So slowly, in fact, that at first I thought it had |
| 197 | completely locked up.</para> |
| 198 | </question> |
| 199 | <answer> |
| 200 | <para>We are not completely sure about this, but one |
| 201 | possibility is that laptops with power management fool |
| 202 | Valgrind's timekeeping mechanism, which is (somewhat in error) |
| 203 | based on the x86 RDTSC instruction. A "fix" which is claimed |
| 204 | to work is to run some other cpu-intensive process at the same |
| 205 | time, so that the laptop's power-management clock-slowing does |
| 206 | not kick in. We would be interested in hearing more feedback |
| 207 | on this.</para> |
| 208 | |
| 209 | <para>Another possible cause is that versions prior to 1.9.6 |
| 210 | did not support threading on glibc 2.3.X systems well. |
| 211 | Hopefully the situation is much improved with 1.9.6 and later |
| 212 | versions.</para> |
| 213 | </answer> |
| 214 | </qandaentry> |
| 215 | |
| 216 | |
| 217 | <qandaentry id="faq.reports"> |
| 218 | <question> |
| 219 | <para>My program uses the C++ STL and string classes. Valgrind |
| 220 | reports 'still reachable' memory leaks involving these classes |
| 221 | at the exit of the program, but there should be none.</para> |
| 222 | </question> |
| 223 | <answer> |
| 224 | <para>First of all: relax, it's probably not a bug, but a |
| 225 | feature. Many implementations of the C++ standard libraries |
| 226 | use their own memory pool allocators. Memory for quite a |
| 227 | number of destructed objects is not immediately freed and given |
| 228 | back to the OS, but kept in the pool(s) for later re-use. The |
| 229 | fact that the pools are not freed at the exit() of the program |
| 230 | cause Valgrind to report this memory as still reachable. The |
| 231 | behaviour not to free pools at the exit() could be called a bug |
| 232 | of the library though.</para> |
| 233 | |
| 234 | <para>Using gcc, you can force the STL to use malloc and to |
| 235 | free memory as soon as possible by globally disabling memory |
| 236 | caching. Beware! Doing so will probably slow down your |
| 237 | program, sometimes drastically.</para> |
| 238 | <itemizedlist> |
| 239 | <listitem> |
| 240 | <para>With gcc 2.91, 2.95, 3.0 and 3.1, compile all source |
| 241 | using the STL with <literal>-D__USE_MALLOC</literal>. Beware! |
| 242 | This is removed from gcc starting with version 3.3.</para> |
| 243 | </listitem> |
| 244 | <listitem> |
njn | 8a5ad76 | 2005-05-12 13:45:56 +0000 | [diff] [blame] | 245 | <para>With gcc 3.2.2 and later, you should export the environment |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 246 | variable <literal>GLIBCPP_FORCE_NEW</literal> before running |
| 247 | your program.</para> |
| 248 | </listitem> |
njn | 8a5ad76 | 2005-05-12 13:45:56 +0000 | [diff] [blame] | 249 | <listitem> |
| 250 | <para>With gcc 3.4 and later, that variable has changed name to |
| 251 | <literal>GLIBCXX_FORCE_NEW</literal>.</para> |
| 252 | </listitem> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 253 | </itemizedlist> |
| 254 | |
| 255 | <para>There are other ways to disable memory pooling: using the |
| 256 | <literal>malloc_alloc</literal> template with your objects (not |
| 257 | portable, but should work for gcc) or even writing your own |
| 258 | memory allocators. But all this goes beyond the scope of this |
| 259 | FAQ. Start by reading <ulink |
| 260 | url="http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3"> |
| 261 | http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3</ulink> |
| 262 | if you absolutely want to do that. But beware:</para> |
| 263 | |
| 264 | <orderedlist> |
| 265 | <listitem> |
| 266 | <para>there are currently changes underway for gcc which are |
| 267 | not totally reflected in the docs right now ("now" == 26 Apr |
| 268 | 03)</para> |
| 269 | </listitem> |
| 270 | <listitem> |
| 271 | <para>allocators belong to the more messy parts of the STL |
njn | d0d6473 | 2005-04-16 14:58:34 +0000 | [diff] [blame] | 272 | and people went to great lengths to make it portable across |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 273 | platforms. Chances are good that your solution will work on |
| 274 | your platform, but not on others.</para> |
| 275 | </listitem> |
| 276 | </orderedlist> |
| 277 | </answer> |
| 278 | </qandaentry> |
| 279 | |
| 280 | |
| 281 | <qandaentry id="faq.unhelpful"> |
| 282 | <question> |
| 283 | <para>The stack traces given by Memcheck (or another tool) |
| 284 | aren't helpful. How can I improve them?</para> |
| 285 | </question> |
| 286 | <answer> |
| 287 | <para>If they're not long enough, use |
| 288 | <literal>--num-callers</literal> to make them longer.</para> |
| 289 | <para>If they're not detailed enough, make sure you are |
| 290 | compiling with <literal>-g</literal> to add debug information. |
| 291 | And don't strip symbol tables (programs should be unstripped |
| 292 | unless you run 'strip' on them; some libraries ship |
| 293 | stripped).</para> |
| 294 | |
njn | 0211ff3 | 2005-05-15 14:49:24 +0000 | [diff] [blame] | 295 | <para>Also, for leak reports involving shared objects, if the shared |
| 296 | object is unloaded before the program terminates, Valgrind will discard |
| 297 | the debug information and the error message will be full of |
| 298 | <literal>???</literal> entries. The workaround here is to avoid calling |
| 299 | dlclose() on these shared objects. |
| 300 | </para> |
| 301 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 302 | <para>Also, <literal>-fomit-frame-pointer</literal> and |
| 303 | <literal>-fstack-check</literal> can make stack traces |
| 304 | worse.</para> |
| 305 | |
| 306 | <para>Some example sub-traces:</para> |
| 307 | |
| 308 | <para>With debug information and unstripped (best):</para> |
| 309 | <programlisting> |
| 310 | Invalid write of size 1 |
| 311 | at 0x80483BF: really (malloc1.c:20) |
| 312 | by 0x8048370: main (malloc1.c:9) |
| 313 | </programlisting> |
| 314 | |
| 315 | <para>With no debug information, unstripped:</para> |
| 316 | <programlisting> |
| 317 | Invalid write of size 1 |
| 318 | at 0x80483BF: really (in /auto/homes/njn25/grind/head5/a.out) |
| 319 | by 0x8048370: main (in /auto/homes/njn25/grind/head5/a.out) |
| 320 | </programlisting> |
| 321 | |
| 322 | <para>With no debug information, stripped:</para> |
| 323 | <programlisting> |
| 324 | Invalid write of size 1 |
| 325 | at 0x80483BF: (within /auto/homes/njn25/grind/head5/a.out) |
| 326 | by 0x8048370: (within /auto/homes/njn25/grind/head5/a.out) |
| 327 | by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so) |
| 328 | by 0x80482CC: (within /auto/homes/njn25/grind/head5/a.out) |
| 329 | </programlisting> |
| 330 | |
| 331 | <para>With debug information and -fomit-frame-pointer:</para> |
| 332 | <programlisting> |
| 333 | Invalid write of size 1 |
| 334 | at 0x80483C4: really (malloc1.c:20) |
| 335 | by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so) |
| 336 | by 0x80482CC: ??? (start.S:81) |
| 337 | </programlisting> |
| 338 | |
njn | 0211ff3 | 2005-05-15 14:49:24 +0000 | [diff] [blame] | 339 | <para>A leak error message involving an unloaded shared object:</para> |
| 340 | |
| 341 | <programlisting> |
| 342 | 84 bytes in 1 blocks are possibly lost in loss record 488 of 713 |
| 343 | at 0x1B9036DA: operator new(unsigned) (vg_replace_malloc.c:132) |
| 344 | by 0x1DB63EEB: ??? |
| 345 | by 0x1DB4B800: ??? |
| 346 | by 0x1D65E007: ??? |
| 347 | by 0x8049EE6: main (main.cpp:24) |
| 348 | </programlisting> |
| 349 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 350 | </answer> |
| 351 | </qandaentry> |
| 352 | |
njn | 16eeb4e | 2005-06-16 03:56:58 +0000 | [diff] [blame] | 353 | <qandaentry id="faq.aliases"> |
| 354 | <question> |
| 355 | <para>The stack traces given by Memcheck (or another tool) seem to |
| 356 | have the wrong function name in them. What's happening?</para> |
| 357 | </question> |
| 358 | <answer> |
| 359 | <para>Occasionally Valgrind stack traces get the wrong function names. |
| 360 | This is caused by glibc using aliases to effectively give one function two |
| 361 | names. Most of the time Valgrind chooses a suitable name, but very |
| 362 | occasionally it gets it wrong. |
| 363 | |
| 364 | Examples we know of are printing 'bcmp' instead of 'memcmp', 'index' |
| 365 | instead of 'strchr', and 'rindex' instead of 'strrchr'.</para> |
| 366 | </answer> |
| 367 | </qandaentry> |
| 368 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 369 | </qandaset> |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 370 | </sect1> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 371 | |
| 372 | |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 373 | <sect1 id="faq.notfound" xreflabel="Memcheck doesn't find my bug"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 374 | <title>Memcheck doesn't find my bug</title> |
| 375 | <qandaset id="qset.notfound"> |
| 376 | |
| 377 | <qandaentry id="faq.hiddenbug"> |
| 378 | <question> |
| 379 | <para>I try running "valgrind --tool=memcheck my_program" and |
| 380 | get Valgrind's startup message, but I don't get any errors and |
| 381 | I know my program has errors.</para> |
| 382 | </question> |
| 383 | <answer> |
njn | a11b9b0 | 2005-03-27 17:05:08 +0000 | [diff] [blame] | 384 | <para>There are two possible causes of this.</para> |
| 385 | |
| 386 | <para>First, by default, Valgrind only traces the top-level process. |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 387 | So if your program spawns children, they won't be traced by |
| 388 | Valgrind by default. Also, if your program is started by a |
| 389 | shell script, Perl script, or something similar, Valgrind will |
| 390 | trace the shell, or the Perl interpreter, or equivalent.</para> |
| 391 | |
| 392 | <para>To trace child processes, use the |
| 393 | <literal>--trace-children=yes</literal> option.</para> |
| 394 | |
| 395 | <para>If you are tracing large trees of processes, it can be |
| 396 | less disruptive to have the output sent over the network. Give |
| 397 | Valgrind the flag |
| 398 | <literal>--log-socket=127.0.0.1:12345</literal> (if you want |
| 399 | logging output sent to <literal>port 12345</literal> on |
| 400 | <literal>localhost</literal>). You can use the |
| 401 | valgrind-listener program to listen on that port:</para> |
| 402 | <programlisting> |
| 403 | valgrind-listener 12345 |
| 404 | </programlisting> |
| 405 | |
| 406 | <para>Obviously you have to start the listener process first. |
| 407 | See the Manual: <ulink url="http://www.valgrind.org/docs/bookset/manual-core.out2file.html">Directing output to file</ulink> for more details.</para> |
njn | a11b9b0 | 2005-03-27 17:05:08 +0000 | [diff] [blame] | 408 | |
| 409 | <para>Second, if your program is statically linked, most Valgrind tools |
| 410 | won't work as well, because they won't be able to replace certain |
| 411 | functions, such as malloc(), with their own versions. A key indicator of |
| 412 | this is if Memcheck says: |
| 413 | <programlisting> |
| 414 | No malloc'd blocks -- no leaks are possible |
| 415 | </programlisting> |
| 416 | when you know your program calls malloc(). The workaround is to avoid |
| 417 | statically linking your program.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 418 | </answer> |
| 419 | </qandaentry> |
| 420 | |
| 421 | |
| 422 | <qandaentry id="faq.overruns"> |
| 423 | <question> |
| 424 | <para>Why doesn't Memcheck find the array overruns in this program?</para> |
| 425 | </question> |
| 426 | <answer> |
| 427 | <programlisting> |
| 428 | int static[5]; |
| 429 | |
| 430 | int main(void) |
| 431 | { |
| 432 | int stack[5]; |
| 433 | |
| 434 | static[5] = 0; |
| 435 | stack [5] = 0; |
| 436 | |
| 437 | return 0; |
| 438 | } |
| 439 | </programlisting> |
| 440 | <para>Unfortunately, Memcheck doesn't do bounds checking on |
| 441 | static or stack arrays. We'd like to, but it's just not |
| 442 | possible to do in a reasonable way that fits with how Memcheck |
| 443 | works. Sorry.</para> |
| 444 | </answer> |
| 445 | </qandaentry> |
| 446 | |
| 447 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 448 | </qandaset> |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 449 | </sect1> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 450 | |
| 451 | |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 452 | <sect1 id="faq.misc" |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 453 | xreflabel="Miscellaneous"> |
| 454 | <title>Miscellaneous</title> |
| 455 | <qandaset id="qset.misc"> |
| 456 | |
| 457 | <qandaentry id="faq.writesupp"> |
| 458 | <question> |
| 459 | <para>I tried writing a suppression but it didn't work. Can |
| 460 | you write my suppression for me?</para> |
| 461 | </question> |
| 462 | <answer> |
| 463 | <para>Yes! Use the |
| 464 | <computeroutput>--gen-suppressions=yes</computeroutput> feature |
| 465 | to spit out suppressions automatically for you. You can then |
| 466 | edit them if you like, eg. combining similar automatically |
| 467 | generated suppressions using wildcards like |
| 468 | <literal>'*'</literal>.</para> |
| 469 | |
| 470 | <para>If you really want to write suppressions by hand, read |
| 471 | the manual carefully. Note particularly that C++ function |
| 472 | names must be <literal>_mangled_</literal>.</para> |
| 473 | </answer> |
| 474 | </qandaentry> |
| 475 | |
| 476 | |
| 477 | <qandaentry id="faq.deflost"> |
| 478 | <question> |
| 479 | <para>With Memcheck/Addrcheck's memory leak detector, what's |
| 480 | the difference between "definitely lost", "possibly lost", |
| 481 | "still reachable", and "suppressed"?</para> |
| 482 | </question> |
| 483 | <answer> |
| 484 | <para>The details are in the Manual: |
| 485 | <ulink url="http://www.valgrind.org/docs/bookset/mc-manual.leaks.html">Memory leak detection</ulink>.</para> |
| 486 | |
| 487 | <para>In short:</para> |
| 488 | <itemizedlist> |
| 489 | <listitem> |
| 490 | <para>"definitely lost" means your program is leaking memory |
| 491 | -- fix it!</para> |
| 492 | </listitem> |
| 493 | <listitem> |
| 494 | <para>"possibly lost" means your program is probably leaking |
| 495 | memory, unless you're doing funny things with |
| 496 | pointers.</para> |
| 497 | </listitem> |
| 498 | <listitem> |
| 499 | <para>"still reachable" means your program is probably ok -- |
| 500 | it didn't free some memory it could have. This is quite |
| 501 | common and often reasonable. Don't use |
| 502 | <computeroutput>--show-reachable=yes</computeroutput> if you |
| 503 | don't want to see these reports.</para> |
| 504 | </listitem> |
| 505 | <listitem> |
| 506 | <para>"suppressed" means that a leak error has been |
| 507 | suppressed. There are some suppressions in the default |
| 508 | suppression files. You can ignore suppressed errors.</para> |
| 509 | </listitem> |
| 510 | </itemizedlist> |
| 511 | </answer> |
| 512 | </qandaentry> |
| 513 | |
| 514 | |
| 515 | </qandaset> |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 516 | </sect1> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 517 | |
| 518 | |
| 519 | <!-- template |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 520 | <sect1 id="faq." |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 521 | xreflabel="xx"> |
| 522 | <title>xx</title> |
| 523 | <qandaset id="qset."> |
| 524 | |
| 525 | <qandaentry id="faq.deflost"> |
| 526 | <question> |
| 527 | <para></para> |
| 528 | </question> |
| 529 | <answer> |
| 530 | <para></para> |
| 531 | </answer> |
| 532 | </qandaentry> |
| 533 | |
| 534 | </qandaset> |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 535 | </sect1> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 536 | --> |
| 537 | |
| 538 | |
| 539 | |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 540 | <sect1 id="faq.help" xreflabel="How To Get Further Assistance"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 541 | <title>How To Get Further Assistance</title> |
| 542 | |
| 543 | |
| 544 | <para>Please read all of this section before posting.</para> |
| 545 | |
| 546 | <para>If you think an answer is incomplete or inaccurate, please |
| 547 | e-mail <ulink url="mailto:&vg-vemail;">&vg-vemail;</ulink>.</para> |
| 548 | |
| 549 | <para>Read the appropriate section(s) of the Manual(s): |
| 550 | <ulink url="http://www.valgrind.org/docs/">Valgrind |
| 551 | Documentation</ulink>.</para> |
| 552 | |
| 553 | <para>Read the <ulink url="http://www.valgrind.org/docs/">Distribution Documents</ulink>.</para> |
| 554 | |
| 555 | <para><ulink url="http://search.gmane.org">Search</ulink> the |
| 556 | <ulink url="http://news.gmane.org/gmane.comp.debugging.valgrind">valgrind-users</ulink> mailing list archives, using the group name |
| 557 | <computeroutput>gmane.comp.debugging.valgrind</computeroutput>.</para> |
| 558 | |
| 559 | <para>Only when you have tried all of these things and are still stuck, |
| 560 | should you post to the <ulink url="&vg-users-list;">valgrind-users |
| 561 | mailing list</ulink>. In which case, please read the following |
| 562 | carefully. Making a complete posting will greatly increase the chances |
| 563 | that an expert or fellow user reading it will have enough information |
| 564 | and motivation to reply.</para> |
| 565 | |
| 566 | <para>Make sure you give full details of the problem, |
| 567 | including the full output of <computeroutput>valgrind |
| 568 | -v</computeroutput>, if applicable. Also which Linux distribution |
| 569 | you're using (Red Hat, Debian, etc) and its version number.</para> |
| 570 | |
| 571 | <para>You are in little danger of making your posting too long |
| 572 | unless you include large chunks of valgrind's (unsuppressed) |
| 573 | output, so err on the side of giving too much information.</para> |
| 574 | |
| 575 | <para>Clearly written subject lines and message bodies are appreciated, |
| 576 | too.</para> |
| 577 | |
| 578 | <para>Finally, remember that, despite the fact that most of the |
| 579 | community are very helpful and responsive to emailed questions, |
| 580 | you are probably requesting help from unpaid volunteers, so you |
| 581 | have no guarantee of receiving an answer.</para> |
| 582 | |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame^] | 583 | </sect1> |
| 584 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 585 | |
| 586 | </book> |