1 2 3Valgrind FAQ 4Release 3.6.0 21 October 2010 5~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 7Table of Contents 81. Background 92. Compiling, installing and configuring 103. Valgrind aborts unexpectedly 114. Valgrind behaves unexpectedly 125. Miscellaneous 136. How To Get Further Assistance 14 15------------------------------------------------------------------------ 161. Background 17------------------------------------------------------------------------ 18 191.1. How do you pronounce "Valgrind"? 20The "Val" as in the world "value". The "grind" is pronounced with a 21short 'i' -- ie. "grinned" (rhymes with "tinned") rather than "grined" 22(rhymes with "find"). 23 24Don't feel bad: almost everyone gets it wrong at first. 25------------------------------------------------------------------------ 26 271.2. Where does the name "Valgrind" come from? 28From Nordic mythology. Originally (before release) the project was named 29Heimdall, after the watchman of the Nordic gods. He could "see a hundred 30miles by day or night, hear the grass growing, see the wool growing on a 31sheep's back", etc. This would have been a great name, but it was 32already taken by a security package "Heimdal". 33 34Keeping with the Nordic theme, Valgrind was chosen. Valgrind is the name 35of the main entrance to Valhalla (the Hall of the Chosen Slain in 36Asgard). Over this entrance there resides a wolf and over it there is 37the head of a boar and on it perches a huge eagle, whose eyes can see to 38the far regions of the nine worlds. Only those judged worthy by the 39guardians are allowed to pass through Valgrind. All others are refused 40entrance. 41 42It's not short for "value grinder", although that's not a bad guess. 43 44------------------------------------------------------------------------ 452. Compiling, installing and configuring 46------------------------------------------------------------------------ 47 482.1. When building Valgrind, 'make' dies partway with an assertion 49failure, something like this: 50 51 % make: expand.c:489: allocated_variable_append: 52 Assertion 'current_variable_set_list->next != 0' failed. 53 54It's probably a bug in 'make'. Some, but not all, instances of version 553.79.1 have this bug, see this: 56<http://www.mail-archive.com/bug-make@gnu.org/msg01658.html>. Try 57upgrading to a more recent version of 'make'. Alternatively, we have 58heard that unsetting the CFLAGS environment variable avoids the problem. 59 60------------------------------------------------------------------------ 61 622.2. When building Valgrind, 'make' fails with this: 63 /usr/bin/ld: cannot find -lc 64 collect2: ld returned 1 exit status 65 66You need to install the glibc-static-devel package. 67 68------------------------------------------------------------------------ 693. Valgrind aborts unexpectedly 70------------------------------------------------------------------------ 71 723.1. Programs run OK on Valgrind, but at exit produce a bunch of errors 73involving __libc_freeres and then die with a segmentation fault. 74 75When the program exits, Valgrind runs the procedure __libc_freeres in 76glibc. This is a hook for memory debuggers, so they can ask glibc to 77free up any memory it has used. Doing that is needed to ensure that 78Valgrind doesn't incorrectly report space leaks in glibc. 79 80The problem is that running __libc_freeres in older glibc versions 81causes this crash. 82 83Workaround for 1.1.X and later versions of Valgrind: use the 84--run-libc-freeres=no option. You may then get space leak reports for 85glibc allocations (please don't report these to the glibc people, since 86they are not real leaks), but at least the program runs. 87 88------------------------------------------------------------------------ 89 903.2. My (buggy) program dies like this: 91 valgrind: m_mallocfree.c:248 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed. 92 93or like this: 94 valgrind: m_mallocfree.c:442 (mk_inuse_bszB): Assertion 'bszB != 0' failed. 95 96or otherwise aborts or crashes in m_mallocfree.c. 97If Memcheck (the memory checker) shows any invalid reads, invalid writes 98or invalid frees in your program, the above may happen. Reason is that 99your program may trash Valgrind's low-level memory manager, which then 100dies with the above assertion, or something similar. The cure is to fix 101your program so that it doesn't do any illegal memory accesses. The 102above failure will hopefully go away after that. 103 104------------------------------------------------------------------------ 105 1063.3. My program dies, printing a message like this along the way: 107 vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x2E 0x5 108 109One possibility is that your program has a bug and erroneously jumps to 110a non-code address, in which case you'll get a SIGILL signal. Memcheck 111may issue a warning just before this happens, but it might not if the 112jump happens to land in addressable memory. 113 114Another possibility is that Valgrind does not handle the instruction. If 115you are using an older Valgrind, a newer version might handle the 116instruction. However, all instruction sets have some obscure, rarely 117used instructions. Also, on amd64 there are an almost limitless number 118of combinations of redundant instruction prefixes, many of them 119undocumented but accepted by CPUs. So Valgrind will still have decoding 120failures from time to time. If this happens, please file a bug report. 121 122------------------------------------------------------------------------ 123 1243.4. I tried running a Java program (or another program that uses a 125just-in-time compiler) under Valgrind but something went wrong. Does 126Valgrind handle such programs? 127 128Valgrind can handle dynamically generated code, so long as none of the 129generated code is later overwritten by other generated code. If this 130happens, though, things will go wrong as Valgrind will continue running 131its translations of the old code (this is true on x86 and amd64, on 132PowerPC there are explicit cache flush instructions which Valgrind 133detects and honours). You should try running with --smc-check=all in 134this case. Valgrind will run much more slowly, but should detect the use 135of the out-of-date code. 136 137Alternatively, if you have the source code to the JIT compiler you can 138insert calls to the VALGRIND_DISCARD_TRANSLATIONS client request to mark 139out-of-date code, saving you from using --smc-check=all. 140 141Apart from this, in theory Valgrind can run any Java program just fine, 142even those that use JNI and are partially implemented in other languages 143like C and C++. In practice, Java implementations tend to do nasty 144things that most programs do not, and Valgrind sometimes falls over 145these corner cases. 146 147If your Java programs do not run under Valgrind, even with 148--smc-check=all, please file a bug report and hopefully we'll be able to 149fix the problem. 150 151 152------------------------------------------------------------------------ 1534. Valgrind behaves unexpectedly 154------------------------------------------------------------------------ 155 1564.1. My program uses the C++ STL and string classes. Valgrind reports 157'still reachable' memory leaks involving these classes at the exit of 158the program, but there should be none. 159 160First of all: relax, it's probably not a bug, but a feature. Many 161implementations of the C++ standard libraries use their own memory pool 162allocators. Memory for quite a number of destructed objects is not 163immediately freed and given back to the OS, but kept in the pool(s) for 164later re-use. The fact that the pools are not freed at the exit of the 165program cause Valgrind to report this memory as still reachable. The 166behaviour not to free pools at the exit could be called a bug of the 167library though. 168 169Using GCC, you can force the STL to use malloc and to free memory as 170soon as possible by globally disabling memory caching. Beware! Doing so 171will probably slow down your program, sometimes drastically. 172 173* With GCC 2.91, 2.95, 3.0 and 3.1, compile all source using the STL 174with -D__USE_MALLOC. Beware! This was removed from GCC starting with 175version 3.3. 176 177* With GCC 3.2.2 and later, you should export the environment variable 178GLIBCPP_FORCE_NEW before running your program. 179 180* With GCC 3.4 and later, that variable has changed name to 181GLIBCXX_FORCE_NEW. 182 183There are other ways to disable memory pooling: using the malloc_alloc 184template with your objects (not portable, but should work for GCC) or 185even writing your own memory allocators. But all this goes beyond the 186scope of this FAQ. Start by reading 187http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_4_leak: 188<http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_4_leak> if you 189absolutely want to do that. But beware: allocators belong to the more 190messy parts of the STL and people went to great lengths to make the STL 191portable across platforms. Chances are good that your solution will work 192on your platform, but not on others. 193 194------------------------------------------------------------------------ 195 1964.2. The stack traces given by Memcheck (or another tool) aren't 197helpful. How can I improve them? 198 199If they're not long enough, use --num-callers to make them longer. 200If they're not detailed enough, make sure you are compiling with -g to 201add debug information. And don't strip symbol tables (programs should be 202unstripped unless you run 'strip' on them; some libraries ship 203stripped). 204 205Also, for leak reports involving shared objects, if the shared object is 206unloaded before the program terminates, Valgrind will discard the debug 207information and the error message will be full of ??? entries. The 208workaround here is to avoid calling dlclose on these shared objects. 209 210Also, -fomit-frame-pointer and -fstack-check can make stack traces 211worse. 212 213Some example sub-traces: 214* With debug information and unstripped (best): 215 Invalid write of size 1 216 at 0x80483BF: really (malloc1.c:20) 217 by 0x8048370: main (malloc1.c:9) 218 219* With no debug information, unstripped: 220 Invalid write of size 1 221 at 0x80483BF: really (in /auto/homes/njn25/grind/head5/a.out) 222 by 0x8048370: main (in /auto/homes/njn25/grind/head5/a.out) 223 224* With no debug information, stripped: 225 Invalid write of size 1 226 at 0x80483BF: (within /auto/homes/njn25/grind/head5/a.out) 227 by 0x8048370: (within /auto/homes/njn25/grind/head5/a.out) 228 by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so) 229 by 0x80482CC: (within /auto/homes/njn25/grind/head5/a.out) 230 231* With debug information and -fomit-frame-pointer: 232 Invalid write of size 1 233 at 0x80483C4: really (malloc1.c:20) 234 by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so) 235 by 0x80482CC: ??? (start.S:81) 236 237* A leak error message involving an unloaded shared object: 238 84 bytes in 1 blocks are possibly lost in loss record 488 of 713 239 at 0x1B9036DA: operator new(unsigned) (vg_replace_malloc.c:132) 240 by 0x1DB63EEB: ??? 241 by 0x1DB4B800: ??? 242 by 0x1D65E007: ??? 243 by 0x8049EE6: main (main.cpp:24) 244 245------------------------------------------------------------------------ 246 2474.3. The stack traces given by Memcheck (or another tool) seem to have 248the wrong function name in them. What's happening? 249 250Occasionally Valgrind stack traces get the wrong function names. This is 251caused by glibc using aliases to effectively give one function two 252names. Most of the time Valgrind chooses a suitable name, but very 253occasionally it gets it wrong. Examples we know of are printing bcmp 254instead of memcmp, index instead of strchr, and rindex instead of 255strrchr. 256 257------------------------------------------------------------------------ 258 2594.4. My program crashes normally, but doesn't under Valgrind, or vice 260versa. What's happening? 261 262When a program runs under Valgrind, its environment is slightly 263different to when it runs natively. For example, the memory layout is 264different, and the way that threads are scheduled is different. 265 266Most of the time this doesn't make any difference, but it can, 267particularly if your program is buggy. For example, if your program 268crashes because it erroneously accesses memory that is unaddressable, 269it's possible that this memory will not be unaddressable when run under 270Valgrind. Alternatively, if your program has data races, these may not 271manifest under Valgrind. 272 273There isn't anything you can do to change this, it's just the nature of 274the way Valgrind works that it cannot exactly replicate a native 275execution environment. In the case where your program crashes due to a 276memory error when run natively but not when run under Valgrind, in most 277cases Memcheck should identify the bad memory operation. 278 279------------------------------------------------------------------------ 280 2814.5. Memcheck doesn't report any errors and I know my program has 282errors. 283 284There are two possible causes of this. 285First, by default, Valgrind only traces the top-level process. So if 286your program spawns children, they won't be traced by Valgrind by 287default. Also, if your program is started by a shell script, Perl 288script, or something similar, Valgrind will trace the shell, or the Perl 289interpreter, or equivalent. 290 291To trace child processes, use the --trace-children=yes option. 292If you are tracing large trees of processes, it can be less disruptive 293to have the output sent over the network. Give Valgrind the option 294--log-socket=127.0.0.1:12345 (if you want logging output sent to port 29512345 on localhost). You can use the valgrind-listener program to listen 296on that port: 297 298 valgrind-listener 12345 299 300Obviously you have to start the listener process first. See the manual 301for more details. 302 303Second, if your program is statically linked, most Valgrind tools won't 304work as well, because they won't be able to replace certain functions, 305such as malloc, with their own versions. A key indicator of this is if 306Memcheck says: All heap blocks were freed -- no leaks are possible when 307you know your program calls malloc. The workaround is to avoid 308statically linking your program. 309 310------------------------------------------------------------------------ 311 3124.6. Why doesn't Memcheck find the array overruns in this program? 313 int static[5]; 314 315 int main(void) 316 { 317 int stack[5]; 318 319 static[5] = 0; 320 stack [5] = 0; 321 322 return 0; 323 } 324 325Unfortunately, Memcheck doesn't do bounds checking on static or stack 326arrays. We'd like to, but it's just not possible to do in a reasonable 327way that fits with how Memcheck works. Sorry. 328 329However, the experimental tool Ptrcheck can detect errors like this. Run 330Valgrind with the --tool=exp-ptrcheck option to try it, but beware that 331it is not as robust as Memcheck. 332 333 334------------------------------------------------------------------------ 3355. Miscellaneous 336------------------------------------------------------------------------ 337 3385.1. I tried writing a suppression but it didn't work. Can you write my 339suppression for me? 340 341Yes! Use the --gen-suppressions=yes feature to spit out suppressions 342automatically for you. You can then edit them if you like, eg. combining 343similar automatically generated suppressions using wildcards like '*'. 344 345If you really want to write suppressions by hand, read the manual 346carefully. Note particularly that C++ function names must be mangled 347(that is, not demangled). 348 349------------------------------------------------------------------------ 350 3515.2. With Memcheck's memory leak detector, what's the difference between 352"definitely lost", "indirectly lost", "possibly lost", "still 353reachable", and "suppressed"? 354 355The details are in the Memcheck section of the user manual. 356In short: 357* "definitely lost" means your program is leaking memory -- fix those 358leaks! 359 360* "indirectly lost" means your program is leaking memory in a 361pointer-based structure. (E.g. if the root node of a binary tree is 362"definitely lost", all the children will be "indirectly lost".) If you 363fix the "definitely lost" leaks, the "indirectly lost" leaks should go 364away. 365 366* "possibly lost" means your program is leaking memory, unless you're 367doing funny things with pointers. This is sometimes reasonable. Use 368--show-possibly-lost=no if you don't want to see these reports. 369 370* "still reachable" means your program is probably ok -- it didn't free 371some memory it could have. This is quite common and often reasonable. 372Don't use --show-reachable=yes if you don't want to see these reports. 373 374* "suppressed" means that a leak error has been suppressed. There are 375some suppressions in the default suppression files. You can ignore 376suppressed errors. 377 378------------------------------------------------------------------------ 379 3805.3. Memcheck's uninitialised value errors are hard to track down, 381because they are often reported some time after they are caused. Could 382Memcheck record a trail of operations to better link the cause to the 383effect? Or maybe just eagerly report any copies of uninitialised memory 384values? 385 386Prior to version 3.4.0, the answer was "we don't know how to do it 387without huge performance penalties". As of 3.4.0, try using the 388--track-origins=yes option. It will run slower than usual, but will give 389you extra information about the origin of uninitialised values. 390 391Or if you want to do it the old fashioned way, you can use the client 392request VALGRIND_CHECK_VALUE_IS_DEFINED to help track these errors down 393-- work backwards from the point where the uninitialised error occurs, 394checking suspect values until you find the cause. This requires editing, 395compiling and re-running your program multiple times, which is a pain, 396but still easier than debugging the problem without Memcheck's help. 397 398As for eager reporting of copies of uninitialised memory values, this 399has been suggested multiple times. Unfortunately, almost all programs 400legitimately copy uninitialised memory values around (because compilers 401pad structs to preserve alignment) and eager checking leads to hundreds 402of false positives. Therefore Memcheck does not support eager checking 403at this time. 404 405------------------------------------------------------------------------ 406 4075.4. Is it possible to attach Valgrind to a program that is already 408running? 409 410No. The environment that Valgrind provides for running programs is 411significantly different to that for normal programs, e.g. due to 412different layout of memory. Therefore Valgrind has to have full control 413from the very start. 414 415It is possible to achieve something like this by running your program 416without any instrumentation (which involves a slow-down of about 5x, 417less than that of most tools), and then adding instrumentation once you 418get to a point of interest. Support for this must be provided by the 419tool, however, and Callgrind is the only tool that currently has such 420support. See the instructions on the callgrind_control program for 421details. 422 423 424------------------------------------------------------------------------ 4256. How To Get Further Assistance 426------------------------------------------------------------------------ 427 428Read the appropriate section(s) of the Valgrind Documentation: 429<http://www.valgrind.org/docs/manual/index.html>. 430 431Search: <http://search.gmane.org> the valgrind-users: 432<http://news.gmane.org/gmane.comp.debugging.valgrind> mailing list 433archives, using the group name gmane.comp.debugging.valgrind. 434 435If you think an answer in this FAQ is incomplete or inaccurate, please 436e-mail valgrind@valgrind.org: <valgrind@valgrind.org>. 437 438If you have tried all of these things and are still stuck, you can try 439mailing the valgrind-users mailing list: 440<http://www.valgrind.org/support/mailing_lists.html>. Note that an email 441has a better change of being answered usefully if it is clearly written. 442Also remember that, despite the fact that most of the community are very 443helpful and responsive to emailed questions, you are probably requesting 444help from unpaid volunteers, so you have no guarantee of receiving an 445answer. 446 447