nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 1 | Valgrind FAQ, version 2.1.2 |
| 2 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 3 | Last revised 6 April 2004 |
| 4 | ~~~~~~~~~~~~~~~~~~~~~~~~~ |
njn | 4e59bd9 | 2003-04-22 20:58:47 +0000 | [diff] [blame] | 5 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 6 | 1. Background |
| 7 | 2. Compiling, installing and configuring |
| 8 | 3. Valgrind aborts unexpectedly |
| 9 | 4. Valgrind behaves unexpectedly |
| 10 | 5. Memcheck doesn't find my bug |
| 11 | 6. Miscellaneous |
| 12 | |
| 13 | |
| 14 | ----------------------------------------------------------------- |
| 15 | 1. Background |
| 16 | ----------------------------------------------------------------- |
| 17 | |
| 18 | 1.1. How do you pronounce "Valgrind"? |
| 19 | |
| 20 | The "Val" as in the world "value". The "grind" is pronounced with a |
| 21 | short 'i' -- ie. "grinned" (rhymes with "tinned") rather than "grined" |
| 22 | (rhymes with "find"). |
| 23 | |
| 24 | Don't feel bad: almost everyone gets it wrong at first. |
njn | 4e59bd9 | 2003-04-22 20:58:47 +0000 | [diff] [blame] | 25 | |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 26 | ----------------------------------------------------------------- |
| 27 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 28 | 1.2. Where does the name "Valgrind" come from? |
| 29 | |
| 30 | From Nordic mythology. Originally (before release) the project was |
| 31 | named Heimdall, after the watchman of the Nordic gods. He could "see a |
| 32 | hundred miles by day or night, hear the grass growing, see the wool |
| 33 | growing on a sheep's back" (etc). This would have been a great name, |
| 34 | but it was already taken by a security package "Heimdal". |
| 35 | |
| 36 | Keeping with the Nordic theme, Valgrind was chosen. Valgrind is the |
| 37 | name of the main entrance to Valhalla (the Hall of the Chosen Slain in |
| 38 | Asgard). Over this entrance there resides a wolf and over it there is |
| 39 | the head of a boar and on it perches a huge eagle, whose eyes can see to |
| 40 | the far regions of the nine worlds. Only those judged worthy by the |
| 41 | guardians are allowed to pass through Valgrind. All others are refused |
| 42 | entrance. |
| 43 | |
| 44 | It's not short for "value grinder", although that's not a bad guess. |
| 45 | |
| 46 | |
| 47 | ----------------------------------------------------------------- |
| 48 | 2. Compiling, installing and configuring |
| 49 | ----------------------------------------------------------------- |
| 50 | |
| 51 | 2.1. When I trying building Valgrind, 'make' dies partway with an |
| 52 | assertion failure, something like this: make: expand.c:489: |
| 53 | |
| 54 | allocated_variable_append: Assertion |
| 55 | `current_variable_set_list->next != 0' failed. |
| 56 | |
| 57 | It's probably a bug in 'make'. Some, but not all, instances of version 3.79.1 |
| 58 | have this bug, see www.mail-archive.com/bug-make@gnu.org/msg01658.html. Try |
| 59 | upgrading to a more recent version of 'make'. Alternatively, we have heard |
| 60 | that unsetting the CFLAGS environment variable avoids the problem. |
| 61 | |
| 62 | |
| 63 | ----------------------------------------------------------------- |
| 64 | 3. Valgrind aborts unexpectedly |
| 65 | ----------------------------------------------------------------- |
| 66 | |
| 67 | 3.1. Programs run OK on Valgrind, but at exit produce a bunch of errors a bit |
| 68 | like this |
njn | 4e59bd9 | 2003-04-22 20:58:47 +0000 | [diff] [blame] | 69 | |
| 70 | ==20755== Invalid read of size 4 |
| 71 | ==20755== at 0x40281C8A: _nl_unload_locale (loadlocale.c:238) |
| 72 | ==20755== by 0x4028179D: free_mem (findlocale.c:257) |
| 73 | ==20755== by 0x402E0962: __libc_freeres (set-freeres.c:34) |
| 74 | ==20755== by 0x40048DCC: vgPlain___libc_freeres_wrapper |
| 75 | (vg_clientfuncs.c:585) |
| 76 | ==20755== Address 0x40CC304C is 8 bytes inside a block of size 380 free'd |
| 77 | ==20755== at 0x400484C9: free (vg_clientfuncs.c:180) |
| 78 | ==20755== by 0x40281CBA: _nl_unload_locale (loadlocale.c:246) |
| 79 | ==20755== by 0x40281218: free_mem (setlocale.c:461) |
| 80 | ==20755== by 0x402E0962: __libc_freeres (set-freeres.c:34) |
| 81 | |
| 82 | and then die with a segmentation fault. |
| 83 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 84 | When the program exits, Valgrind runs the procedure __libc_freeres() in |
| 85 | glibc. This is a hook for memory debuggers, so they can ask glibc to |
| 86 | free up any memory it has used. Doing that is needed to ensure that |
| 87 | Valgrind doesn't incorrectly report space leaks in glibc. |
njn | 4e59bd9 | 2003-04-22 20:58:47 +0000 | [diff] [blame] | 88 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 89 | Problem is that running __libc_freeres() in older glibc versions causes |
| 90 | this crash. |
njn | 4e59bd9 | 2003-04-22 20:58:47 +0000 | [diff] [blame] | 91 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 92 | WORKAROUND FOR 1.1.X and later versions of Valgrind: use the |
| 93 | --run-libc-freeres=no flag. You may then get space leak reports for |
| 94 | glibc-allocations (please _don't_ report these to the glibc people, |
| 95 | since they are not real leaks), but at least the program runs. |
njn | 4e59bd9 | 2003-04-22 20:58:47 +0000 | [diff] [blame] | 96 | |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 97 | ----------------------------------------------------------------- |
njn | 4e59bd9 | 2003-04-22 20:58:47 +0000 | [diff] [blame] | 98 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 99 | 3.2. My (buggy) program dies like this: |
njn | 4e59bd9 | 2003-04-22 20:58:47 +0000 | [diff] [blame] | 100 | valgrind: vg_malloc2.c:442 (bszW_to_pszW): |
| 101 | Assertion `pszW >= 0' failed. |
njn | 4e59bd9 | 2003-04-22 20:58:47 +0000 | [diff] [blame] | 102 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 103 | If Memcheck (the memory checker) shows any invalid reads, invalid writes |
| 104 | and invalid frees in your program, the above may happen. Reason is that |
| 105 | your program may trash Valgrind's low-level memory manager, which then |
| 106 | dies with the above assertion, or something like this. The cure is to |
| 107 | fix your program so that it doesn't do any illegal memory accesses. The |
| 108 | above failure will hopefully go away after that. |
njn | 4e59bd9 | 2003-04-22 20:58:47 +0000 | [diff] [blame] | 109 | |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 110 | ----------------------------------------------------------------- |
njn | 4e59bd9 | 2003-04-22 20:58:47 +0000 | [diff] [blame] | 111 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 112 | 3.3. My program dies, printing a message like this along the way: |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 113 | |
nethercote | 3178887 | 2003-11-02 16:32:05 +0000 | [diff] [blame] | 114 | disInstr: unhandled instruction bytes: 0x66 0xF 0x2E 0x5 |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 115 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 116 | Older versions did not support some x86 instructions, particularly |
| 117 | SSE/SSE2 instructions. Try a newer Valgrind; we now support almost all |
| 118 | instructions. If it still happens with newer versions, if the failing |
| 119 | instruction is an SSE/SSE2 instruction, you might be able to recompile |
| 120 | your progrma without it by using the flag -march to gcc. Either way, |
| 121 | let us know and we'll try to fix it. |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 122 | |
| 123 | ----------------------------------------------------------------- |
| 124 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 125 | 3.4. My program dies like this: |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 126 | |
| 127 | error: /lib/librt.so.1: symbol __pthread_clock_settime, version |
| 128 | GLIBC_PRIVATE not defined in file libpthread.so.0 with link time |
| 129 | reference |
| 130 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 131 | This is a total swamp. Nevertheless there is a way out. It's a problem |
| 132 | which is not easy to fix. Really the problem is that /lib/librt.so.1 |
| 133 | refers to some symbols __pthread_clock_settime and |
| 134 | __pthread_clock_gettime in /lib/libpthread.so which are not intended to |
| 135 | be exported, ie they are private. |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 136 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 137 | Best solution is to ensure your program does not use /lib/librt.so.1. |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 138 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 139 | However .. since you're probably not using it directly, or even |
| 140 | knowingly, that's hard to do. You might instead be able to fix it by |
| 141 | playing around with coregrind/vg_libpthread.vs. Things to try: |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 142 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 143 | Remove this |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 144 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 145 | GLIBC_PRIVATE { |
| 146 | __pthread_clock_gettime; |
| 147 | __pthread_clock_settime; |
| 148 | }; |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 149 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 150 | or maybe remove this |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 151 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 152 | GLIBC_2.2.3 { |
| 153 | __pthread_clock_gettime; |
| 154 | __pthread_clock_settime; |
| 155 | } GLIBC_2.2; |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 156 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 157 | or maybe add this |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 158 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 159 | GLIBC_2.2.4 { |
| 160 | __pthread_clock_gettime; |
| 161 | __pthread_clock_settime; |
| 162 | } GLIBC_2.2; |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 163 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 164 | GLIBC_2.2.5 { |
| 165 | __pthread_clock_gettime; |
| 166 | __pthread_clock_settime; |
| 167 | } GLIBC_2.2; |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 168 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 169 | or some combination of the above. After each change you need to delete |
| 170 | coregrind/libpthread.so and do make && make install. |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 171 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 172 | I just don't know if any of the above will work. If you can find a |
| 173 | solution which works, I would be interested to hear it. |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 174 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 175 | To which someone replied: |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 176 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 177 | I deleted this: |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 178 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 179 | GLIBC_2.2.3 { |
| 180 | __pthread_clock_gettime; |
| 181 | __pthread_clock_settime; |
| 182 | } GLIBC_2.2; |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 183 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 184 | and it worked. |
| 185 | |
| 186 | |
| 187 | ----------------------------------------------------------------- |
| 188 | 4. Valgrind behaves unexpectedly |
| 189 | ----------------------------------------------------------------- |
| 190 | |
| 191 | 4.1. I try running "valgrind my_program", but my_program runs normally, |
| 192 | and Valgrind doesn't emit any output at all. |
| 193 | |
| 194 | For versions prior to 2.1.1: |
| 195 | |
| 196 | Valgrind doesn't work out-of-the-box with programs that are entirely |
| 197 | statically linked. It does a quick test at startup, and if it detects |
| 198 | that the program is statically linked, it aborts with an explanation. |
| 199 | |
| 200 | This test may fail in some obscure cases, eg. if you run a script under |
| 201 | Valgrind and the script interpreter is statically linked. |
| 202 | |
| 203 | If you still want static linking, you can ask gcc to link certain |
| 204 | libraries statically. Try the following options: |
| 205 | |
| 206 | -Wl,-Bstatic -lmyLibrary1 -lotherLibrary -Wl,-Bdynamic |
| 207 | |
| 208 | Just make sure you end with -Wl,-Bdynamic so that libc is dynamically |
| 209 | linked. |
| 210 | |
| 211 | If you absolutely cannot use dynamic libraries, you can try statically |
| 212 | linking together all the .o files in coregrind/, all the .o files of the |
| 213 | tool of your choice (eg. those in memcheck/), and the .o files of your |
| 214 | program. You'll end up with a statically linked binary that runs |
| 215 | permanently under Valgrind's control. Note that we haven't tested this |
| 216 | procedure thoroughly. |
| 217 | |
| 218 | |
| 219 | For versions 2.1.1 and later: |
| 220 | |
| 221 | Valgrind does now work with static binaries, although beware that some |
| 222 | of the tools won't operate as well as normal, because they have access |
| 223 | to less information about how the program runs. Eg. Memcheck will miss |
| 224 | some errors that it would otherwise find. This is because Valgrind |
| 225 | doesn't replace malloc() and friends with its own versions. It's best |
| 226 | if your program is dynamically linked with glibc. |
sewardj | 36a53ad | 2003-04-22 23:26:24 +0000 | [diff] [blame] | 227 | |
| 228 | ----------------------------------------------------------------- |
njn | 4e59bd9 | 2003-04-22 20:58:47 +0000 | [diff] [blame] | 229 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 230 | 4.2. My threaded server process runs unbelievably slowly on Valgrind. |
| 231 | So slowly, in fact, that at first I thought it had completely |
| 232 | locked up. |
sewardj | 03272ff | 2003-04-26 22:23:35 +0000 | [diff] [blame] | 233 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 234 | We are not completely sure about this, but one possibility is that |
| 235 | laptops with power management fool Valgrind's timekeeping mechanism, |
| 236 | which is (somewhat in error) based on the x86 RDTSC instruction. A |
| 237 | "fix" which is claimed to work is to run some other cpu-intensive |
| 238 | process at the same time, so that the laptop's power-management |
| 239 | clock-slowing does not kick in. We would be interested in hearing more |
| 240 | feedback on this. |
sewardj | 03272ff | 2003-04-26 22:23:35 +0000 | [diff] [blame] | 241 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 242 | Another possible cause is that versions prior to 1.9.6 did not support |
| 243 | threading on glibc 2.3.X systems well. Hopefully the situation is much |
| 244 | improved with 1.9.6 and later versions. |
sewardj | 03272ff | 2003-04-26 22:23:35 +0000 | [diff] [blame] | 245 | |
| 246 | ----------------------------------------------------------------- |
| 247 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 248 | 4.3. My program uses the C++ STL and string classes. Valgrind |
| 249 | reports 'still reachable' memory leaks involving these classes |
| 250 | at the exit of the program, but there should be none. |
njn | ae34aef | 2003-08-07 21:24:24 +0000 | [diff] [blame] | 251 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 252 | First of all: relax, it's probably not a bug, but a feature. Many |
| 253 | implementations of the C++ standard libraries use their own memory pool |
| 254 | allocators. Memory for quite a number of destructed objects is not |
| 255 | immediately freed and given back to the OS, but kept in the pool(s) for |
| 256 | later re-use. The fact that the pools are not freed at the exit() of |
| 257 | the program cause Valgrind to report this memory as still reachable. |
| 258 | The behaviour not to free pools at the exit() could be called a bug of |
| 259 | the library though. |
njn | ae34aef | 2003-08-07 21:24:24 +0000 | [diff] [blame] | 260 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 261 | Using gcc, you can force the STL to use malloc and to free memory as |
| 262 | soon as possible by globally disabling memory caching. Beware! Doing |
| 263 | so will probably slow down your program, sometimes drastically. |
njn | ae34aef | 2003-08-07 21:24:24 +0000 | [diff] [blame] | 264 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 265 | - With gcc 2.91, 2.95, 3.0 and 3.1, compile all source using the STL |
| 266 | with -D__USE_MALLOC. Beware! This is removed from gcc starting with |
| 267 | version 3.3. |
| 268 | |
| 269 | - With 3.2.2 and later, you should export the environment variable |
| 270 | GLIBCPP_FORCE_NEW before running your program. |
| 271 | |
| 272 | There are other ways to disable memory pooling: using the malloc_alloc |
| 273 | template with your objects (not portable, but should work for gcc) or |
| 274 | even writing your own memory allocators. But all this goes beyond the |
| 275 | scope of this FAQ. Start by reading |
| 276 | http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3 if you |
| 277 | absolutely want to do that. But beware: |
| 278 | |
| 279 | 1) there are currently changes underway for gcc which are not totally |
| 280 | reflected in the docs right now ("now" == 26 Apr 03) |
| 281 | |
| 282 | 2) allocators belong to the more messy parts of the STL and people went |
| 283 | at great lengths to make it portable across platforms. Chances are |
| 284 | good that your solution will work on your platform, but not on |
| 285 | others. |
| 286 | |
| 287 | ----------------------------------------------------------------------------- |
| 288 | 4.4. The stack traces given by Memcheck (or another tool) aren't helpful. |
| 289 | How can I improve them? |
| 290 | |
| 291 | If they're not long enough, use --num-callers to make them longer. |
| 292 | |
| 293 | If they're not detailed enough, make sure you are compiling with -g to add |
| 294 | debug information. And don't strip symbol tables (programs should be |
| 295 | unstripped unless you run 'strip' on them; some libraries ship stripped). |
| 296 | |
| 297 | Also, -fomit-frame-pointer and -fstack-check can make stack traces worse. |
| 298 | |
| 299 | Some example sub-traces: |
| 300 | |
| 301 | With debug information and unstripped (best): |
| 302 | |
| 303 | Invalid write of size 1 |
| 304 | at 0x80483BF: really (malloc1.c:20) |
| 305 | by 0x8048370: main (malloc1.c:9) |
| 306 | |
| 307 | With no debug information, unstripped: |
| 308 | |
| 309 | Invalid write of size 1 |
| 310 | at 0x80483BF: really (in /auto/homes/njn25/grind/head5/a.out) |
| 311 | by 0x8048370: main (in /auto/homes/njn25/grind/head5/a.out) |
| 312 | |
| 313 | With no debug information, stripped: |
| 314 | |
| 315 | Invalid write of size 1 |
| 316 | at 0x80483BF: (within /auto/homes/njn25/grind/head5/a.out) |
| 317 | by 0x8048370: (within /auto/homes/njn25/grind/head5/a.out) |
| 318 | by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so) |
| 319 | by 0x80482CC: (within /auto/homes/njn25/grind/head5/a.out) |
| 320 | |
| 321 | With debug information and -fomit-frame-pointer: |
| 322 | |
| 323 | Invalid write of size 1 |
| 324 | at 0x80483C4: really (malloc1.c:20) |
| 325 | by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so) |
| 326 | by 0x80482CC: ??? (start.S:81) |
| 327 | |
| 328 | ----------------------------------------------------------------- |
| 329 | 5. Memcheck doesn't find my bug |
| 330 | ----------------------------------------------------------------- |
| 331 | |
| 332 | 5.1. I try running "valgrind --tool=memcheck my_program" and get |
| 333 | Valgrind's startup message, but I don't get any errors and I know |
| 334 | my program has errors. |
| 335 | |
| 336 | By default, Valgrind only traces the top-level process. So if your |
| 337 | program spawns children, they won't be traced by Valgrind by default. |
| 338 | Also, if your program is started by a shell script, Perl script, or |
| 339 | something similar, Valgrind will trace the shell, or the Perl |
| 340 | interpreter, or equivalent. |
| 341 | |
| 342 | To trace child processes, use the --trace-children=yes option. |
| 343 | |
| 344 | If you are tracing large trees of processes, it can be less disruptive |
| 345 | to have the output sent over the network. Give Valgrind the flag |
nethercote | f854867 | 2004-06-21 12:42:35 +0000 | [diff] [blame^] | 346 | --log-socket=127.0.0.1:12345 (if you want logging output sent to port |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 347 | 12345 on localhost). You can use the valgrind-listener program to |
| 348 | listen on that port: |
| 349 | |
| 350 | valgrind-listener 12345 |
| 351 | |
| 352 | Obviously you have to start the listener process first. See the |
| 353 | documentation for more details. |
njn | ae34aef | 2003-08-07 21:24:24 +0000 | [diff] [blame] | 354 | |
| 355 | ----------------------------------------------------------------- |
| 356 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 357 | 5.2. Why doesn't Memcheck find the array overruns in this program? |
| 358 | |
| 359 | int static[5]; |
| 360 | |
| 361 | int main(void) |
| 362 | { |
| 363 | int stack[5]; |
| 364 | |
| 365 | static[5] = 0; |
| 366 | stack [5] = 0; |
| 367 | |
| 368 | return 0; |
| 369 | } |
| 370 | |
| 371 | Unfortunately, Memcheck doesn't do bounds checking on static or stack |
| 372 | arrays. We'd like to, but it's just not possible to do in a reasonable |
| 373 | way that fits with how Memcheck works. Sorry. |
njn | 1aa1850 | 2003-08-15 07:35:20 +0000 | [diff] [blame] | 374 | |
| 375 | ----------------------------------------------------------------- |
| 376 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 377 | 5.3. My program dies with a segmentation fault, but Memcheck doesn't give |
| 378 | any error messages before it, or none that look related. |
njn | a8fb5a3 | 2003-08-20 11:19:17 +0000 | [diff] [blame] | 379 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 380 | One possibility is that your program accesses to memory with |
| 381 | inappropriate permissions set, such as writing to read-only memory. |
| 382 | Maybe your program is writing to a static string like this: |
njn | a8fb5a3 | 2003-08-20 11:19:17 +0000 | [diff] [blame] | 383 | |
nethercote | ef0abd1 | 2004-04-10 00:29:58 +0000 | [diff] [blame] | 384 | char* s = "hello"; |
| 385 | s[0] = 'j'; |
| 386 | |
| 387 | or something similar. Writing to read-only memory can also apparently |
| 388 | make LinuxThreads behave strangely. |
| 389 | |
| 390 | |
| 391 | ----------------------------------------------------------------- |
| 392 | 6. Miscellaneous |
| 393 | ----------------------------------------------------------------- |
| 394 | |
| 395 | 6.1. I tried writing a suppression but it didn't work. Can you |
| 396 | write my suppression for me? |
| 397 | |
| 398 | Yes! Use the --gen-suppressions=yes feature to spit out suppressions |
| 399 | automatically for you. You can then edit them if you like, eg. |
| 400 | combining similar automatically generated suppressions using wildcards |
| 401 | like '*'. |
| 402 | |
| 403 | If you really want to write suppressions by hand, read the manual |
| 404 | carefully. Note particularly that C++ function names must be _mangled_. |
| 405 | |
| 406 | ----------------------------------------------------------------- |
| 407 | |
| 408 | 6.2. With Memcheck/Addrcheck's memory leak detector, what's the |
| 409 | difference between "definitely lost", "possibly lost", "still |
| 410 | reachable", and "suppressed"? |
| 411 | |
| 412 | The details are in section 3.6 of the manual. |
| 413 | |
| 414 | In short: |
| 415 | |
| 416 | - "definitely lost" means your program is leaking memory -- fix it! |
| 417 | |
| 418 | - "possibly lost" means your program is probably leaking memory, |
| 419 | unless you're doing funny things with pointers. |
| 420 | |
| 421 | - "still reachable" means your program is probably ok -- it didn't |
| 422 | free some memory it could have. This is quite common and often |
| 423 | reasonable. Don't use --show-reachable=yes if you don't want to see |
| 424 | these reports. |
| 425 | |
| 426 | - "suppressed" means that a leak error has been suppressed. There are |
| 427 | some suppressions in the default suppression files. You can ignore |
| 428 | suppressed errors. |
njn | a8fb5a3 | 2003-08-20 11:19:17 +0000 | [diff] [blame] | 429 | |
| 430 | ----------------------------------------------------------------- |
| 431 | |
njn | 4e59bd9 | 2003-04-22 20:58:47 +0000 | [diff] [blame] | 432 | (this is the end of the FAQ.) |