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 7<book id="FAQ" xreflabel="Valgrind FAQ"> 8 9<bookinfo> 10 <title>Valgrind FAQ</title> 11 <releaseinfo>&rel-type; &rel-version; &rel-date;</releaseinfo> 12 <copyright> 13 <year>&vg-lifespan;</year> 14 <holder><ulink url="&vg-devs-url;">Valgrind Developers</ulink></holder> 15 </copyright> 16 <legalnotice> 17 <para>Email: <ulink url="mailto:&vg-vemail;">&vg-vemail;</ulink></para> 18 </legalnotice> 19</bookinfo> 20 21 22<article id="faq"> 23<title>Valgrind Frequently Asked Questions</title> 24 25 26<!-- FAQ starts here --> 27<qandaset> 28 29 30<!-- Background --> 31<qandadiv id="faq.background" xreflabel="Background"> 32<title>Background</title> 33 34<qandaentry id="faq.pronounce"> 35 <question id="q-pronounce"> 36 <para>How do you pronounce "Valgrind"?</para> 37 </question> 38 <answer id="a-pronounce"> 39 <para>The "Val" as in the world "value". The "grind" is pronounced 40 with a short 'i' -- ie. "grinned" (rhymes with "tinned") rather than 41 "grined" (rhymes with "find").</para> <para>Don't feel bad: almost 42 everyone gets it wrong at first.</para> 43 </answer> 44</qandaentry> 45 46<qandaentry id="faq.whence"> 47 <question id="q-whence"> 48 <para>Where does the name "Valgrind" come from?</para> 49 </question> 50 <answer id="a-whence"> 51 52 <para>From Nordic mythology. Originally (before release) the project 53 was named Heimdall, after the watchman of the Nordic gods. He could 54 "see a hundred miles by day or night, hear the grass growing, see the 55 wool growing on a sheep's back", etc. This would have been a great 56 name, but it was already taken by a security package "Heimdal".</para> 57 58 <para>Keeping with the Nordic theme, Valgrind was chosen. Valgrind is 59 the name of the main entrance to Valhalla (the Hall of the Chosen 60 Slain in Asgard). Over this entrance there resides a wolf and over it 61 there is the head of a boar and on it perches a huge eagle, whose eyes 62 can see to the far regions of the nine worlds. Only those judged 63 worthy by the guardians are allowed to pass through Valgrind. All 64 others are refused entrance.</para> 65 66 <para>It's not short for "value grinder", although that's not a bad 67 guess.</para> 68 </answer> 69 </qandaentry> 70 71</qandadiv> 72 73 74 75<!-- Compiling, Installing and Configuring --> 76<qandadiv id="faq.installing" xreflabel="Compiling, installing and configuring"> 77<title>Compiling, installing and configuring</title> 78 79<qandaentry id="faq.make_dies"> 80 <question id="q-make_dies"> 81 <para>When building Valgrind, 'make' dies partway with 82 an assertion failure, something like this:</para> 83<screen> 84% make: expand.c:489: allocated_variable_append: 85 Assertion 'current_variable_set_list->next != 0' failed. 86</screen> 87 </question> 88 <answer id="a-make_dies"> 89 <para>It's probably a bug in 'make'. Some, but not all, instances of 90 version 3.79.1 have this bug, see 91 <ulink url="http://www.mail-archive.com/bug-make@gnu.org/msg01658.html">this</ulink>. 92 Try upgrading to a more recent version of 'make'. Alternatively, we have 93 heard that unsetting the CFLAGS environment variable avoids the 94 problem.</para> 95 </answer> 96</qandaentry> 97 98<qandaentry id="faq.glibc_devel"> 99 <question> 100 <para>When building Valgrind, 'make' fails with this:</para> 101<screen> 102/usr/bin/ld: cannot find -lc 103collect2: ld returned 1 exit status 104</screen> 105 </question> 106 <answer> 107 <para>You need to install the glibc-static-devel package.</para> 108 </answer> 109</qandaentry> 110 111</qandadiv> 112 113 114<!-- Valgrind aborts unexpectedly --> 115<qandadiv id="faq.abort" xreflabel="Valgrind aborts unexpectedly"> 116<title>Valgrind aborts unexpectedly</title> 117 118<qandaentry id="faq.exit_errors"> 119 <question id="q-exit_errors"> 120 <para>Programs run OK on Valgrind, but at exit produce a bunch of 121 errors involving <literal>__libc_freeres</literal> and then die 122 with a segmentation fault.</para> 123 </question> 124 <answer id="a-exit_errors"> 125 <para>When the program exits, Valgrind runs the procedure 126 <function>__libc_freeres</function> in glibc. This is a hook for 127 memory debuggers, so they can ask glibc to free up any memory it has 128 used. Doing that is needed to ensure that Valgrind doesn't 129 incorrectly report space leaks in glibc.</para> 130 131 <para>The problem is that running <literal>__libc_freeres</literal> in 132 older glibc versions causes this crash.</para> 133 134 <para>Workaround for 1.1.X and later versions of Valgrind: use the 135 <option>--run-libc-freeres=no</option> option. You may then get space 136 leak reports for glibc allocations (please don't report these to 137 the glibc people, since they are not real leaks), but at least the 138 program runs.</para> 139 </answer> 140</qandaentry> 141 142<qandaentry id="faq.bugdeath"> 143 <question id="q-bugdeath"> 144 <para>My (buggy) program dies like this:</para> 145<screen>valgrind: m_mallocfree.c:248 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.</screen> 146 <para>or like this:</para> 147<screen>valgrind: m_mallocfree.c:442 (mk_inuse_bszB): Assertion 'bszB != 0' failed.</screen> 148 <para>or otherwise aborts or crashes in m_mallocfree.c.</para> 149 150 </question> 151 <answer id="a-bugdeath"> 152 <para>If Memcheck (the memory checker) shows any invalid reads, 153 invalid writes or invalid frees in your program, the above may 154 happen. Reason is that your program may trash Valgrind's low-level 155 memory manager, which then dies with the above assertion, or 156 something similar. The cure is to fix your program so that it 157 doesn't do any illegal memory accesses. The above failure will 158 hopefully go away after that.</para> 159 </answer> 160</qandaentry> 161 162<qandaentry id="faq.msgdeath"> 163 <question id="q-msgdeath"> 164 <para>My program dies, printing a message like this along the 165 way:</para> 166<screen>vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x2E 0x5</screen> 167 </question> 168 <answer id="a-msgdeath"> 169 <para>One possibility is that your program has a bug and erroneously 170 jumps to a non-code address, in which case you'll get a SIGILL signal. 171 Memcheck may issue a warning just before this happens, but it might not 172 if the jump happens to land in addressable memory.</para> 173 174 <para>Another possibility is that Valgrind does not handle the 175 instruction. If you are using an older Valgrind, a newer version might 176 handle the instruction. However, all instruction sets have some 177 obscure, rarely used instructions. Also, on amd64 there are an almost 178 limitless number of combinations of redundant instruction prefixes, many 179 of them undocumented but accepted by CPUs. So Valgrind will still have 180 decoding failures from time to time. If this happens, please file a bug 181 report.</para> 182 </answer> 183</qandaentry> 184 185<qandaentry id="faq.java"> 186 <question id="q-java"> 187 <para>I tried running a Java program (or another program that uses a 188 just-in-time compiler) under Valgrind but something went wrong. 189 Does Valgrind handle such programs?</para> 190 </question> 191 <answer id="a-java"> 192 <para>Valgrind can handle dynamically generated code, so long as 193 none of the generated code is later overwritten by other generated 194 code. If this happens, though, things will go wrong as Valgrind 195 will continue running its translations of the old code (this is true 196 on x86 and amd64, on PowerPC there are explicit cache flush 197 instructions which Valgrind detects and honours). 198 You should try running with 199 <option>--smc-check=all</option> in this case. Valgrind will run 200 much more slowly, but should detect the use of the out-of-date 201 code.</para> 202 203 <para>Alternatively, if you have the source code to the JIT compiler 204 you can insert calls to the 205 <computeroutput>VALGRIND_DISCARD_TRANSLATIONS</computeroutput> 206 client request to mark out-of-date code, saving you from using 207 <option>--smc-check=all</option>.</para> 208 209 <para>Apart from this, in theory Valgrind can run any Java program 210 just fine, even those that use JNI and are partially implemented in 211 other languages like C and C++. In practice, Java implementations 212 tend to do nasty things that most programs do not, and Valgrind 213 sometimes falls over these corner cases.</para> 214 215 <para>If your Java programs do not run under Valgrind, even with 216 <option>--smc-check=all</option>, please file a bug report and 217 hopefully we'll be able to fix the problem.</para> 218 </answer> 219</qandaentry> 220 221</qandadiv> 222 223 224<!-- Valgrind behaves unexpectedly --> 225<qandadiv id="faq.unexpected" xreflabel="Valgrind behaves unexpectedly"> 226<title>Valgrind behaves unexpectedly</title> 227 228<qandaentry id="faq.reports"> 229 <question id="q-reports"> 230 <para>My program uses the C++ STL and string classes. Valgrind 231 reports 'still reachable' memory leaks involving these classes at 232 the exit of the program, but there should be none.</para> 233 </question> 234 <answer id="a-reports"> 235 <para>First of all: relax, it's probably not a bug, but a feature. 236 Many implementations of the C++ standard libraries use their own 237 memory pool allocators. Memory for quite a number of destructed 238 objects is not immediately freed and given back to the OS, but kept 239 in the pool(s) for later re-use. The fact that the pools are not 240 freed at the exit of the program cause Valgrind to report this 241 memory as still reachable. The behaviour not to free pools at the 242 exit could be called a bug of the library though.</para> 243 244 <para>Using GCC, you can force the STL to use malloc and to free 245 memory as soon as possible by globally disabling memory caching. 246 Beware! Doing so will probably slow down your program, sometimes 247 drastically.</para> 248 <itemizedlist> 249 <listitem> 250 <para>With GCC 2.91, 2.95, 3.0 and 3.1, compile all source using 251 the STL with <literal>-D__USE_MALLOC</literal>. Beware! This was 252 removed from GCC starting with version 3.3.</para> 253 </listitem> 254 <listitem> 255 <para>With GCC 3.2.2 and later, you should export the 256 environment variable <literal>GLIBCPP_FORCE_NEW</literal> before 257 running your program.</para> 258 </listitem> 259 <listitem> 260 <para>With GCC 3.4 and later, that variable has changed name to 261 <literal>GLIBCXX_FORCE_NEW</literal>.</para> 262 </listitem> 263 </itemizedlist> 264 265 <para>There are other ways to disable memory pooling: using the 266 <literal>malloc_alloc</literal> template with your objects (not 267 portable, but should work for GCC) or even writing your own memory 268 allocators. But all this goes beyond the scope of this FAQ. Start 269 by reading 270 <ulink 271 url="http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_4_leak"> 272 http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_4_leak</ulink> 273 if you absolutely want to do that. But beware: 274 allocators belong to the more messy parts of the STL and 275 people went to great lengths to make the STL portable across 276 platforms. Chances are good that your solution will work on your 277 platform, but not on others.</para> 278 </answer> 279</qandaentry> 280 281 282<qandaentry id="faq.unhelpful"> 283 <question id="q-unhelpful"> 284 <para>The stack traces given by Memcheck (or another tool) aren't 285 helpful. How can I improve them?</para> 286 </question> 287 <answer id="a-unhelpful"> 288 <para>If they're not long enough, use <option>--num-callers</option> 289 to make them longer.</para> 290 291 <para>If they're not detailed enough, make sure you are compiling 292 with <option>-g</option> to add debug information. And don't strip 293 symbol tables (programs should be unstripped unless you run 'strip' 294 on them; some libraries ship stripped).</para> 295 296 <para>Also, for leak reports involving shared objects, if the shared 297 object is unloaded before the program terminates, Valgrind will 298 discard the debug information and the error message will be full of 299 <literal>???</literal> entries. The workaround here is to avoid 300 calling <function>dlclose</function> on these shared objects.</para> 301 302 <para>Also, <option>-fomit-frame-pointer</option> and 303 <option>-fstack-check</option> can make stack traces worse.</para> 304 305 <para>Some example sub-traces:</para> 306 307 <itemizedlist> 308 <listitem> 309 <para>With debug information and unstripped (best):</para> 310<programlisting> 311Invalid write of size 1 312 at 0x80483BF: really (malloc1.c:20) 313 by 0x8048370: main (malloc1.c:9) 314</programlisting> 315 </listitem> 316 317 <listitem> 318 <para>With no debug information, unstripped:</para> 319<programlisting> 320Invalid write of size 1 321 at 0x80483BF: really (in /auto/homes/njn25/grind/head5/a.out) 322 by 0x8048370: main (in /auto/homes/njn25/grind/head5/a.out) 323</programlisting> 324 </listitem> 325 326 <listitem> 327 <para>With no debug information, stripped:</para> 328<programlisting> 329Invalid write of size 1 330 at 0x80483BF: (within /auto/homes/njn25/grind/head5/a.out) 331 by 0x8048370: (within /auto/homes/njn25/grind/head5/a.out) 332 by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so) 333 by 0x80482CC: (within /auto/homes/njn25/grind/head5/a.out) 334</programlisting> 335 </listitem> 336 337 <listitem> 338 <para>With debug information and -fomit-frame-pointer:</para> 339<programlisting> 340Invalid write of size 1 341 at 0x80483C4: really (malloc1.c:20) 342 by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so) 343 by 0x80482CC: ??? (start.S:81) 344</programlisting> 345 </listitem> 346 347 <listitem> 348 <para>A leak error message involving an unloaded shared object:</para> 349<programlisting> 35084 bytes in 1 blocks are possibly lost in loss record 488 of 713 351 at 0x1B9036DA: operator new(unsigned) (vg_replace_malloc.c:132) 352 by 0x1DB63EEB: ??? 353 by 0x1DB4B800: ??? 354 by 0x1D65E007: ??? 355 by 0x8049EE6: main (main.cpp:24) 356</programlisting> 357 </listitem> 358 </itemizedlist> 359 360 </answer> 361</qandaentry> 362 363<qandaentry id="faq.aliases"> 364 <question id="q-aliases"> 365 <para>The stack traces given by Memcheck (or another tool) seem to 366 have the wrong function name in them. What's happening?</para> 367 </question> 368 <answer id="a-aliases"> 369 <para>Occasionally Valgrind stack traces get the wrong function 370 names. This is caused by glibc using aliases to effectively give 371 one function two names. Most of the time Valgrind chooses a 372 suitable name, but very occasionally it gets it wrong. Examples we know 373 of are printing <function>bcmp</function> instead of 374 <function>memcmp</function>, <function>index</function> instead of 375 <function>strchr</function>, and <function>rindex</function> instead of 376 <function>strrchr</function>.</para> 377 </answer> 378</qandaentry> 379 380 381<qandaentry id="faq.crashes"> 382 <question id="q-crashes"> 383 <para>My program crashes normally, but doesn't under Valgrind, or vice 384 versa. What's happening?</para> 385 </question> 386 <answer id="a-crashes"> 387 <para>When a program runs under Valgrind, its environment is slightly 388 different to when it runs natively. For example, the memory layout is 389 different, and the way that threads are scheduled is different.</para> 390 391 <para>Most of the time this doesn't make any difference, but it can, 392 particularly if your program is buggy. For example, if your program 393 crashes because it erroneously accesses memory that is unaddressable, 394 it's possible that this memory will not be unaddressable when run under 395 Valgrind. Alternatively, if your program has data races, these may not 396 manifest under Valgrind.</para> 397 398 <para>There isn't anything you can do to change this, it's just the 399 nature of the way Valgrind works that it cannot exactly replicate a 400 native execution environment. In the case where your program crashes 401 due to a memory error when run natively but not when run under Valgrind, 402 in most cases Memcheck should identify the bad memory operation.</para>. 403 </answer> 404</qandaentry> 405 406 407 408<qandaentry id="faq.hiddenbug"> 409 <question id="q-hiddenbug"> 410 <para> Memcheck doesn't report any errors and I know my program has 411 errors.</para> 412 </question> 413 <answer id="a-hiddenbug"> 414 <para>There are two possible causes of this.</para> 415 416 <para>First, by default, Valgrind only traces the top-level process. 417 So if your program spawns children, they won't be traced by Valgrind 418 by default. Also, if your program is started by a shell script, 419 Perl script, or something similar, Valgrind will trace the shell, or 420 the Perl interpreter, or equivalent.</para> 421 422 <para>To trace child processes, use the 423 <option>--trace-children=yes</option> option.</para> 424 425 <para>If you are tracing large trees of processes, it can be less 426 disruptive to have the output sent over the network. Give Valgrind 427 the option <option>--log-socket=127.0.0.1:12345</option> (if you want 428 logging output sent to port <literal>12345</literal> on 429 <literal>localhost</literal>). You can use the valgrind-listener 430 program to listen on that port:</para> 431<programlisting> 432valgrind-listener 12345 433</programlisting> 434 435 <para>Obviously you have to start the listener process first. See 436 the manual for more details.</para> 437 438 <para>Second, if your program is statically linked, most Valgrind 439 tools will only work well if they are able to replace certain 440 functions, such as <function>malloc</function>, with their own 441 versions. By default, statically linked <function>malloc 442 functions</function> are not replaced. A key indicator of this is 443 if Memcheck says: 444<programlisting> 445All heap blocks were freed -- no leaks are possible 446</programlisting> 447 when you know your program calls <function>malloc</function>. The 448 workaround is to use the option 449 <option>--soname-synonyms=somalloc=NONE</option> 450 or to avoid statically linking your program.</para> 451 452 <para>There will also be no replacement if you use an alternative 453 <function>malloc library</function> such as tcmalloc, jemalloc, 454 ... In such a case, the 455 option <option>--soname-synonyms=somalloc=zzzz</option> (where 456 zzzz is the soname of the alternative malloc library) will allow 457 Valgrind to replace the functions.</para> 458 </answer> 459</qandaentry> 460 461 462<qandaentry id="faq.overruns"> 463 <question id="q-overruns"> 464 <para>Why doesn't Memcheck find the array overruns in this 465 program?</para> 466<programlisting> 467int static[5]; 468 469int main(void) 470{ 471 int stack[5]; 472 473 static[5] = 0; 474 stack [5] = 0; 475 476 return 0; 477} 478</programlisting> 479 </question> 480 <answer id="a-overruns"> 481 <para>Unfortunately, Memcheck doesn't do bounds checking on global 482 or stack arrays. We'd like to, but it's just not possible to do in 483 a reasonable way that fits with how Memcheck works. Sorry.</para> 484 485 <para>However, the experimental tool SGcheck can detect errors like 486 this. Run Valgrind with the <option>--tool=exp-sgcheck</option> option 487 to try it, but be aware that it is not as robust as Memcheck.</para> 488 </answer> 489</qandaentry> 490 491</qandadiv> 492 493 494 495<!-- Miscellaneous --> 496<qandadiv id="faq.misc" xreflabel="Miscellaneous"> 497<title>Miscellaneous</title> 498 499<qandaentry id="faq.writesupp"> 500 <question id="q-writesupp"> 501 <para>I tried writing a suppression but it didn't work. Can you 502 write my suppression for me?</para> 503 </question> 504 <answer id="a-writesupp"> 505 <para>Yes! Use the <option>--gen-suppressions=yes</option> feature 506 to spit out suppressions automatically for you. You can then edit 507 them if you like, eg. combining similar automatically generated 508 suppressions using wildcards like <literal>'*'</literal>.</para> 509 510 <para>If you really want to write suppressions by hand, read the 511 manual carefully. Note particularly that C++ function names must be 512 mangled (that is, not demangled).</para> 513 </answer> 514</qandaentry> 515 516 517<qandaentry id="faq.deflost"> 518 <question id="q-deflost"> 519 <para>With Memcheck's memory leak detector, what's the 520 difference between "definitely lost", "indirectly lost", "possibly 521 lost", "still reachable", and "suppressed"?</para> 522 </question> 523 <answer id="a-deflost"> 524 <para>The details are in the Memcheck section of the user manual.</para> 525 526 <para>In short:</para> 527 <itemizedlist> 528 <listitem> 529 <para>"definitely lost" means your program is leaking memory -- 530 fix those leaks!</para> 531 </listitem> 532 <listitem> 533 <para>"indirectly lost" means your program is leaking memory in 534 a pointer-based structure. (E.g. if the root node of a binary tree 535 is "definitely lost", all the children will be "indirectly lost".) 536 If you fix the "definitely lost" leaks, the "indirectly lost" leaks 537 should go away. 538 </para> 539 </listitem> 540 <listitem> 541 <para>"possibly lost" means your program is leaking 542 memory, unless you're doing unusual things with pointers that could 543 cause them to point into the middle of an allocated block; see the 544 user manual for some possible causes. Use 545 <option>--show-possibly-lost=no</option> if you don't want to see 546 these reports.</para> 547 </listitem> 548 <listitem> 549 <para>"still reachable" means your program is probably ok -- it 550 didn't free some memory it could have. This is quite common and 551 often reasonable. Don't use 552 <option>--show-reachable=yes</option> if you don't want to see 553 these reports.</para> 554 </listitem> 555 <listitem> 556 <para>"suppressed" means that a leak error has been suppressed. 557 There are some suppressions in the default suppression files. 558 You can ignore suppressed errors.</para> 559 </listitem> 560 </itemizedlist> 561 </answer> 562</qandaentry> 563 564<qandaentry id="faq.undeferrors"> 565 <question id="q-undeferrors"> 566 <para>Memcheck's uninitialised value errors are hard to track down, 567 because they are often reported some time after they are caused. Could 568 Memcheck record a trail of operations to better link the cause to the 569 effect? Or maybe just eagerly report any copies of uninitialised 570 memory values?</para> 571 </question> 572 <answer id="a-undeferrors"> 573 <para>Prior to version 3.4.0, the answer was "we don't know how to do it 574 without huge performance penalties". As of 3.4.0, try using the 575 <option>--track-origins=yes</option> option. It will run slower than 576 usual, but will give you extra information about the origin of 577 uninitialised values.</para> 578 579 <para>Or if you want to do it the old fashioned way, you can use the 580 client request 581 <computeroutput>VALGRIND_CHECK_VALUE_IS_DEFINED</computeroutput> to help 582 track these errors down -- work backwards from the point where the 583 uninitialised error occurs, checking suspect values until you find the 584 cause. This requires editing, compiling and re-running your program 585 multiple times, which is a pain, but still easier than debugging the 586 problem without Memcheck's help.</para> 587 588 <para>As for eager reporting of copies of uninitialised memory values, 589 this has been suggested multiple times. Unfortunately, almost all 590 programs legitimately copy uninitialised memory values around (because 591 compilers pad structs to preserve alignment) and eager checking leads to 592 hundreds of false positives. Therefore Memcheck does not support eager 593 checking at this time.</para> 594 </answer> 595</qandaentry> 596 597 598<qandaentry id="faq.attach"> 599 <question id="q-attach"> 600 <para>Is it possible to attach Valgrind to a program that is already 601 running?</para> 602 </question> 603 <answer id="a-attach"> 604 <para>No. The environment that Valgrind provides for running programs 605 is significantly different to that for normal programs, e.g. due to 606 different layout of memory. Therefore Valgrind has to have full control 607 from the very start.</para> 608 609 <para>It is possible to achieve something like this by running your 610 program without any instrumentation (which involves a slow-down of about 611 5x, less than that of most tools), and then adding instrumentation once 612 you get to a point of interest. Support for this must be provided by 613 the tool, however, and Callgrind is the only tool that currently has 614 such support. See the instructions on the 615 <computeroutput>callgrind_control</computeroutput> program for details. 616 </para> 617 </answer> 618</qandaentry> 619 620 621</qandadiv> 622 623 624 625<!-- Further Assistance --> 626<qandadiv id="faq.help" xreflabel="How To Get Further Assistance"> 627<title>How To Get Further Assistance</title> 628 629<!-- WARNING: this file should not xref other parts of the docs, because it 630is built standalone as FAQ.txt. That's why we link to, for example, the 631online copy of the manual. --> 632 633<qandaentry id="e-help"> 634 <!-- <question><para/></question> --> 635 <answer id="a-help"> 636 <para>Read the appropriate section(s) of the 637 <ulink url="&vg-docs-url;">Valgrind Documentation</ulink>.</para> 638 639 <para><ulink url="http://search.gmane.org">Search</ulink> the 640 <ulink url="http://news.gmane.org/gmane.comp.debugging.valgrind">valgrind-users</ulink> mailing list archives, using the group name 641 <computeroutput>gmane.comp.debugging.valgrind</computeroutput>.</para> 642 643 <para>If you think an answer in this FAQ is incomplete or inaccurate, please 644 e-mail <ulink url="mailto:&vg-vemail;">&vg-vemail;</ulink>.</para> 645 646 <para>If you have tried all of these things and are still 647 stuck, you can try mailing the 648 <ulink url="&vg-lists-url;">valgrind-users mailing list</ulink>. 649 Note that an email has a better change of being answered usefully if it is 650 clearly written. Also remember that, despite the fact that most of the 651 community are very helpful and responsive to emailed questions, you are 652 probably requesting help from unpaid volunteers, so you have no guarantee 653 of receiving an answer.</para> 654</answer> 655 656</qandaentry> 657</qandadiv> 658 659 660<!-- FAQ ends here --> 661</qandaset> 662 663 664 665<!-- template 666<qandadiv id="faq.installing" xreflabel="Installing"> 667<title>Installing</title> 668 669<qandaentry id="faq.problem"> 670 <question id="q-problem"> 671 <para></para> 672 </question> 673 <answer id="a-problem"> 674 <para></para> 675 </answer> 676</qandaentry> 677 678</qandadiv> 679--> 680 681</article> 682 683</book> 684