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 | |
de | 252c614 | 2005-11-27 04:10:00 +0000 | [diff] [blame] | 6 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 7 | <book id="FAQ" xreflabel="Valgrind FAQ"> |
de | 53ad684 | 2005-11-19 03:28:10 +0000 | [diff] [blame] | 8 | |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame] | 9 | <bookinfo> |
de | 53ad684 | 2005-11-19 03:28:10 +0000 | [diff] [blame] | 10 | <title>Valgrind FAQ</title> |
de | 53ad684 | 2005-11-19 03:28:10 +0000 | [diff] [blame] | 11 | <releaseinfo>&rel-type; &rel-version; &rel-date;</releaseinfo> |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 12 | <copyright> |
| 13 | <year>&vg-lifespan;</year> |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 14 | <holder><ulink url="&vg-devs-url;">Valgrind Developers</ulink></holder> |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 15 | </copyright> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 16 | <legalnotice> |
| 17 | <para>Email: <ulink url="mailto:&vg-vemail;">&vg-vemail;</ulink></para> |
| 18 | </legalnotice> |
de | e9b715c | 2005-08-03 20:28:33 +0000 | [diff] [blame] | 19 | </bookinfo> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 20 | |
de | 53ad684 | 2005-11-19 03:28:10 +0000 | [diff] [blame] | 21 | |
de | 252c614 | 2005-11-27 04:10:00 +0000 | [diff] [blame] | 22 | <article id="faq"> |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 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"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 32 | <title>Background</title> |
| 33 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 34 | <qandaentry id="faq.pronounce"> |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 35 | <question id="q-pronounce"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 36 | <para>How do you pronounce "Valgrind"?</para> |
| 37 | </question> |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 38 | <answer id="a-pronounce"> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 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> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 43 | </answer> |
| 44 | </qandaentry> |
| 45 | |
| 46 | <qandaentry id="faq.whence"> |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 47 | <question id="q-whence"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 48 | <para>Where does the name "Valgrind" come from?</para> |
| 49 | </question> |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 50 | <answer id="a-whence"> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 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 |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 55 | wool growing on a sheep's back", etc. This would have been a great |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 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> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 68 | </answer> |
| 69 | </qandaentry> |
| 70 | |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 71 | </qandadiv> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 72 | |
| 73 | |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 74 | |
| 75 | <!-- Compiling, Installing and Configuring --> |
| 76 | <qandadiv id="faq.installing" xreflabel="Compiling, installing and configuring"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 77 | <title>Compiling, installing and configuring</title> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 78 | |
| 79 | <qandaentry id="faq.make_dies"> |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 80 | <question id="q-make_dies"> |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 81 | <para>When building Valgrind, 'make' dies partway with |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 82 | an assertion failure, something like this:</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 83 | <screen> |
| 84 | % make: expand.c:489: allocated_variable_append: |
| 85 | Assertion 'current_variable_set_list->next != 0' failed. |
| 86 | </screen> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 87 | </question> |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 88 | <answer id="a-make_dies"> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 89 | <para>It's probably a bug in 'make'. Some, but not all, instances of |
| 90 | version 3.79.1 have this bug, see |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 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> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 95 | </answer> |
| 96 | </qandaentry> |
| 97 | |
njn | a874ef4 | 2006-04-06 14:04:48 +0000 | [diff] [blame] | 98 | <qandaentry id="faq.glibc_devel"> |
| 99 | <question> |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 100 | <para>When building Valgrind, 'make' fails with this:</para> |
| 101 | <screen> |
njn | a874ef4 | 2006-04-06 14:04:48 +0000 | [diff] [blame] | 102 | /usr/bin/ld: cannot find -lc |
| 103 | collect2: ld returned 1 exit status |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 104 | </screen> |
njn | a874ef4 | 2006-04-06 14:04:48 +0000 | [diff] [blame] | 105 | </question> |
| 106 | <answer> |
| 107 | <para>You need to install the glibc-static-devel package.</para> |
| 108 | </answer> |
| 109 | </qandaentry> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 110 | |
njn | a874ef4 | 2006-04-06 14:04:48 +0000 | [diff] [blame] | 111 | </qandadiv> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 112 | |
| 113 | |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 114 | <!-- Valgrind aborts unexpectedly --> |
| 115 | <qandadiv id="faq.abort" xreflabel="Valgrind aborts unexpectedly"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 116 | <title>Valgrind aborts unexpectedly</title> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 117 | |
| 118 | <qandaentry id="faq.exit_errors"> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 119 | <question id="q-exit_errors"> |
| 120 | <para>Programs run OK on Valgrind, but at exit produce a bunch of |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 121 | errors involving <literal>__libc_freeres</literal> and then die |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 122 | with a segmentation fault.</para> |
| 123 | </question> |
| 124 | <answer id="a-exit_errors"> |
| 125 | <para>When the program exits, Valgrind runs the procedure |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 126 | <function>__libc_freeres</function> in glibc. This is a hook for |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 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 | |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 131 | <para>The problem is that running <literal>__libc_freeres</literal> in |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 132 | older glibc versions causes this crash.</para> |
| 133 | |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 134 | <para>Workaround for 1.1.X and later versions of Valgrind: use the |
njn | f4b4758 | 2009-08-10 01:15:30 +0000 | [diff] [blame] | 135 | <option>--run-libc-freeres=no</option> option. You may then get space |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 136 | leak reports for glibc allocations (please don't report these to |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 137 | the glibc people, since they are not real leaks), but at least the |
| 138 | program runs.</para> |
| 139 | </answer> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 140 | </qandaentry> |
| 141 | |
| 142 | <qandaentry id="faq.bugdeath"> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 143 | <question id="q-bugdeath"> |
| 144 | <para>My (buggy) program dies like this:</para> |
njn | b8329f0 | 2009-04-16 00:33:20 +0000 | [diff] [blame] | 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> |
njn | 557bb83 | 2009-05-18 23:03:52 +0000 | [diff] [blame] | 148 | <para>or otherwise aborts or crashes in m_mallocfree.c.</para> |
njn | b8329f0 | 2009-04-16 00:33:20 +0000 | [diff] [blame] | 149 | |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 150 | </question> |
| 151 | <answer id="a-bugdeath"> |
| 152 | <para>If Memcheck (the memory checker) shows any invalid reads, |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 153 | invalid writes or invalid frees in your program, the above may |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 154 | happen. Reason is that your program may trash Valgrind's low-level |
| 155 | memory manager, which then dies with the above assertion, or |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 156 | something similar. The cure is to fix your program so that it |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 157 | doesn't do any illegal memory accesses. The above failure will |
| 158 | hopefully go away after that.</para> |
| 159 | </answer> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 160 | </qandaentry> |
| 161 | |
| 162 | <qandaentry id="faq.msgdeath"> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 163 | <question id="q-msgdeath"> |
| 164 | <para>My program dies, printing a message like this along the |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 165 | way:</para> |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 166 | <screen>vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x2E 0x5</screen> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 167 | </question> |
| 168 | <answer id="a-msgdeath"> |
njn | b8329f0 | 2009-04-16 00:33:20 +0000 | [diff] [blame] | 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 |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 181 | report.</para> |
njn | 7316df2 | 2009-08-04 01:16:01 +0000 | [diff] [blame] | 182 | </answer> |
| 183 | </qandaentry> |
| 184 | |
njn | dde37b4 | 2005-10-06 18:58:33 +0000 | [diff] [blame] | 185 | <qandaentry id="faq.java"> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 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 |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 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 |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 200 | much more slowly, but should detect the use of the out-of-date |
| 201 | code.</para> |
| 202 | |
sewardj | 3387889 | 2007-11-17 09:43:25 +0000 | [diff] [blame] | 203 | <para>Alternatively, if you have the source code to the JIT compiler |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 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> |
njn | dde37b4 | 2005-10-06 18:58:33 +0000 | [diff] [blame] | 219 | </qandaentry> |
| 220 | |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 221 | </qandadiv> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 222 | |
| 223 | |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 224 | <!-- Valgrind behaves unexpectedly --> |
| 225 | <qandadiv id="faq.unexpected" xreflabel="Valgrind behaves unexpectedly"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 226 | <title>Valgrind behaves unexpectedly</title> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 227 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 228 | <qandaentry id="faq.reports"> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 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 |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 240 | freed at the exit of the program cause Valgrind to report this |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 241 | memory as still reachable. The behaviour not to free pools at the |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 242 | exit could be called a bug of the library though.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 243 | |
njn | 7316df2 | 2009-08-04 01:16:01 +0000 | [diff] [blame] | 244 | <para>Using GCC, you can force the STL to use malloc and to free |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 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> |
njn | 7316df2 | 2009-08-04 01:16:01 +0000 | [diff] [blame] | 250 | <para>With GCC 2.91, 2.95, 3.0 and 3.1, compile all source using |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 251 | the STL with <literal>-D__USE_MALLOC</literal>. Beware! This was |
njn | 7316df2 | 2009-08-04 01:16:01 +0000 | [diff] [blame] | 252 | removed from GCC starting with version 3.3.</para> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 253 | </listitem> |
| 254 | <listitem> |
njn | 7316df2 | 2009-08-04 01:16:01 +0000 | [diff] [blame] | 255 | <para>With GCC 3.2.2 and later, you should export the |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 256 | environment variable <literal>GLIBCPP_FORCE_NEW</literal> before |
| 257 | running your program.</para> |
| 258 | </listitem> |
| 259 | <listitem> |
njn | 7316df2 | 2009-08-04 01:16:01 +0000 | [diff] [blame] | 260 | <para>With GCC 3.4 and later, that variable has changed name to |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 261 | <literal>GLIBCXX_FORCE_NEW</literal>.</para> |
| 262 | </listitem> |
| 263 | </itemizedlist> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 264 | |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 265 | <para>There are other ways to disable memory pooling: using the |
| 266 | <literal>malloc_alloc</literal> template with your objects (not |
njn | 7316df2 | 2009-08-04 01:16:01 +0000 | [diff] [blame] | 267 | portable, but should work for GCC) or even writing your own memory |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 268 | allocators. But all this goes beyond the scope of this FAQ. Start |
| 269 | by reading |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 270 | <ulink |
| 271 | url="http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_4_leak"> |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 272 | http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_4_leak</ulink> |
| 273 | if you absolutely want to do that. But beware: |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 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> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 278 | </answer> |
| 279 | </qandaentry> |
| 280 | |
| 281 | |
| 282 | <qandaentry id="faq.unhelpful"> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 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> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 290 | |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 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> |
njn | 0211ff3 | 2005-05-15 14:49:24 +0000 | [diff] [blame] | 295 | |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 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 |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 300 | calling <function>dlclose</function> on these shared objects.</para> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 301 | |
| 302 | <para>Also, <option>-fomit-frame-pointer</option> and |
| 303 | <option>-fstack-check</option> can make stack traces worse.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 304 | |
| 305 | <para>Some example sub-traces:</para> |
| 306 | |
njn | 15d7c34 | 2005-09-30 01:43:32 +0000 | [diff] [blame] | 307 | <itemizedlist> |
| 308 | <listitem> |
| 309 | <para>With debug information and unstripped (best):</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 310 | <programlisting> |
| 311 | Invalid write of size 1 |
| 312 | at 0x80483BF: really (malloc1.c:20) |
| 313 | by 0x8048370: main (malloc1.c:9) |
| 314 | </programlisting> |
njn | 15d7c34 | 2005-09-30 01:43:32 +0000 | [diff] [blame] | 315 | </listitem> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 316 | |
njn | 15d7c34 | 2005-09-30 01:43:32 +0000 | [diff] [blame] | 317 | <listitem> |
| 318 | <para>With no debug information, unstripped:</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 319 | <programlisting> |
| 320 | Invalid 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> |
njn | 15d7c34 | 2005-09-30 01:43:32 +0000 | [diff] [blame] | 324 | </listitem> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 325 | |
njn | 15d7c34 | 2005-09-30 01:43:32 +0000 | [diff] [blame] | 326 | <listitem> |
| 327 | <para>With no debug information, stripped:</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 328 | <programlisting> |
| 329 | Invalid 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> |
njn | 15d7c34 | 2005-09-30 01:43:32 +0000 | [diff] [blame] | 335 | </listitem> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 336 | |
njn | 15d7c34 | 2005-09-30 01:43:32 +0000 | [diff] [blame] | 337 | <listitem> |
| 338 | <para>With debug information and -fomit-frame-pointer:</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 339 | <programlisting> |
| 340 | Invalid 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> |
njn | 15d7c34 | 2005-09-30 01:43:32 +0000 | [diff] [blame] | 345 | </listitem> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 346 | |
njn | 15d7c34 | 2005-09-30 01:43:32 +0000 | [diff] [blame] | 347 | <listitem> |
| 348 | <para>A leak error message involving an unloaded shared object:</para> |
njn | 0211ff3 | 2005-05-15 14:49:24 +0000 | [diff] [blame] | 349 | <programlisting> |
| 350 | 84 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> |
njn | 15d7c34 | 2005-09-30 01:43:32 +0000 | [diff] [blame] | 357 | </listitem> |
| 358 | </itemizedlist> |
njn | 0211ff3 | 2005-05-15 14:49:24 +0000 | [diff] [blame] | 359 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 360 | </answer> |
| 361 | </qandaentry> |
| 362 | |
njn | 16eeb4e | 2005-06-16 03:56:58 +0000 | [diff] [blame] | 363 | <qandaentry id="faq.aliases"> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 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 |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 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> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 377 | </answer> |
njn | 16eeb4e | 2005-06-16 03:56:58 +0000 | [diff] [blame] | 378 | </qandaentry> |
| 379 | |
njn | 6e9a3df | 2007-09-25 22:05:04 +0000 | [diff] [blame] | 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 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 406 | |
| 407 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 408 | <qandaentry id="faq.hiddenbug"> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 409 | <question id="q-hiddenbug"> |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 410 | <para> Memcheck doesn't report any errors and I know my program has |
| 411 | errors.</para> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 412 | </question> |
| 413 | <answer id="a-hiddenbug"> |
| 414 | <para>There are two possible causes of this.</para> |
njn | a11b9b0 | 2005-03-27 17:05:08 +0000 | [diff] [blame] | 415 | |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 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> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 421 | |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 422 | <para>To trace child processes, use the |
| 423 | <option>--trace-children=yes</option> option.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 424 | |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 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 |
njn | f4b4758 | 2009-08-10 01:15:30 +0000 | [diff] [blame] | 427 | the option <option>--log-socket=127.0.0.1:12345</option> (if you want |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 428 | logging output sent to port <literal>12345</literal> on |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 429 | <literal>localhost</literal>). You can use the valgrind-listener |
| 430 | program to listen on that port:</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 431 | <programlisting> |
| 432 | valgrind-listener 12345 |
| 433 | </programlisting> |
| 434 | |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 435 | <para>Obviously you have to start the listener process first. See |
| 436 | the manual for more details.</para> |
njn | a11b9b0 | 2005-03-27 17:05:08 +0000 | [diff] [blame] | 437 | |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 438 | <para>Second, if your program is statically linked, most Valgrind |
| 439 | tools won't work as well, because they won't be able to replace |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 440 | certain functions, such as <function>malloc</function>, with their own |
| 441 | versions. A key indicator of this is if Memcheck says: |
njn | a11b9b0 | 2005-03-27 17:05:08 +0000 | [diff] [blame] | 442 | <programlisting> |
njn | 5666ee6 | 2005-12-19 19:38:02 +0000 | [diff] [blame] | 443 | All heap blocks were freed -- no leaks are possible |
njn | a11b9b0 | 2005-03-27 17:05:08 +0000 | [diff] [blame] | 444 | </programlisting> |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 445 | when you know your program calls <function>malloc</function>. The |
| 446 | workaround is to avoid statically linking your program.</para> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 447 | </answer> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 448 | </qandaentry> |
| 449 | |
| 450 | |
| 451 | <qandaentry id="faq.overruns"> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 452 | <question id="q-overruns"> |
| 453 | <para>Why doesn't Memcheck find the array overruns in this |
| 454 | program?</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 455 | <programlisting> |
| 456 | int static[5]; |
| 457 | |
| 458 | int main(void) |
| 459 | { |
| 460 | int stack[5]; |
| 461 | |
| 462 | static[5] = 0; |
| 463 | stack [5] = 0; |
| 464 | |
| 465 | return 0; |
| 466 | } |
| 467 | </programlisting> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 468 | </question> |
| 469 | <answer id="a-overruns"> |
| 470 | <para>Unfortunately, Memcheck doesn't do bounds checking on static |
| 471 | or stack arrays. We'd like to, but it's just not possible to do in |
| 472 | a reasonable way that fits with how Memcheck works. Sorry.</para> |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 473 | |
| 474 | <para>However, the experimental tool Ptrcheck can detect errors like |
| 475 | this. Run Valgrind with the <option>--tool=exp-ptrcheck</option> option |
| 476 | to try it, but beware that it is not as robust as Memcheck.</para> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 477 | </answer> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 478 | </qandaentry> |
| 479 | |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 480 | </qandadiv> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 481 | |
| 482 | |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 483 | |
| 484 | <!-- Miscellaneous --> |
| 485 | <qandadiv id="faq.misc" xreflabel="Miscellaneous"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 486 | <title>Miscellaneous</title> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 487 | |
| 488 | <qandaentry id="faq.writesupp"> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 489 | <question id="q-writesupp"> |
| 490 | <para>I tried writing a suppression but it didn't work. Can you |
| 491 | write my suppression for me?</para> |
| 492 | </question> |
| 493 | <answer id="a-writesupp"> |
| 494 | <para>Yes! Use the <option>--gen-suppressions=yes</option> feature |
| 495 | to spit out suppressions automatically for you. You can then edit |
| 496 | them if you like, eg. combining similar automatically generated |
| 497 | suppressions using wildcards like <literal>'*'</literal>.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 498 | |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 499 | <para>If you really want to write suppressions by hand, read the |
| 500 | manual carefully. Note particularly that C++ function names must be |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 501 | mangled (that is, not demangled).</para> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 502 | </answer> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 503 | </qandaentry> |
| 504 | |
| 505 | |
| 506 | <qandaentry id="faq.deflost"> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 507 | <question id="q-deflost"> |
njn | 1d0825f | 2006-03-27 11:37:07 +0000 | [diff] [blame] | 508 | <para>With Memcheck's memory leak detector, what's the |
njn | 8225cc0 | 2009-03-09 22:52:24 +0000 | [diff] [blame] | 509 | difference between "definitely lost", "indirectly lost", "possibly |
| 510 | lost", "still reachable", and "suppressed"?</para> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 511 | </question> |
| 512 | <answer id="a-deflost"> |
njn | 8225cc0 | 2009-03-09 22:52:24 +0000 | [diff] [blame] | 513 | <para>The details are in the Memcheck section of the user manual.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 514 | |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 515 | <para>In short:</para> |
| 516 | <itemizedlist> |
| 517 | <listitem> |
| 518 | <para>"definitely lost" means your program is leaking memory -- |
njn | 8225cc0 | 2009-03-09 22:52:24 +0000 | [diff] [blame] | 519 | fix those leaks!</para> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 520 | </listitem> |
| 521 | <listitem> |
njn | 8225cc0 | 2009-03-09 22:52:24 +0000 | [diff] [blame] | 522 | <para>"indirectly lost" means your program is leaking memory in |
| 523 | a pointer-based structure. (E.g. if the root node of a binary tree |
| 524 | is "definitely lost", all the children will be "indirectly lost".) |
| 525 | If you fix the "definitely lost" leaks, the "indirectly lost" leaks |
| 526 | should go away. |
| 527 | </para> |
| 528 | </listitem> |
| 529 | <listitem> |
| 530 | <para>"possibly lost" means your program is leaking |
bart | 3cedf57 | 2010-08-26 10:56:27 +0000 | [diff] [blame] | 531 | memory, unless you're doing funny things with pointers. |
| 532 | This is sometimes reasonable. Use |
| 533 | <option>--show-possibly-lost=no</option> if you don't want to see |
| 534 | these reports.</para> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 535 | </listitem> |
| 536 | <listitem> |
| 537 | <para>"still reachable" means your program is probably ok -- it |
| 538 | didn't free some memory it could have. This is quite common and |
| 539 | often reasonable. Don't use |
| 540 | <option>--show-reachable=yes</option> if you don't want to see |
| 541 | these reports.</para> |
| 542 | </listitem> |
| 543 | <listitem> |
| 544 | <para>"suppressed" means that a leak error has been suppressed. |
| 545 | There are some suppressions in the default suppression files. |
| 546 | You can ignore suppressed errors.</para> |
| 547 | </listitem> |
| 548 | </itemizedlist> |
| 549 | </answer> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 550 | </qandaentry> |
| 551 | |
njn | 3fdb362 | 2006-10-20 22:16:57 +0000 | [diff] [blame] | 552 | <qandaentry id="faq.undeferrors"> |
| 553 | <question id="q-undeferrors"> |
| 554 | <para>Memcheck's uninitialised value errors are hard to track down, |
| 555 | because they are often reported some time after they are caused. Could |
| 556 | Memcheck record a trail of operations to better link the cause to the |
| 557 | effect? Or maybe just eagerly report any copies of uninitialised |
| 558 | memory values?</para> |
| 559 | </question> |
| 560 | <answer id="a-undeferrors"> |
njn | bb97c5e | 2008-12-13 22:27:05 +0000 | [diff] [blame] | 561 | <para>Prior to version 3.4.0, the answer was "we don't know how to do it |
| 562 | without huge performance penalties". As of 3.4.0, try using the |
njn | f4b4758 | 2009-08-10 01:15:30 +0000 | [diff] [blame] | 563 | <option>--track-origins=yes</option> option. It will run slower than |
njn | bb97c5e | 2008-12-13 22:27:05 +0000 | [diff] [blame] | 564 | usual, but will give you extra information about the origin of |
| 565 | uninitialised values.</para> |
njn | 3fdb362 | 2006-10-20 22:16:57 +0000 | [diff] [blame] | 566 | |
njn | bb97c5e | 2008-12-13 22:27:05 +0000 | [diff] [blame] | 567 | <para>Or if you want to do it the old fashioned way, you can use the |
| 568 | client request |
njn | 3fdb362 | 2006-10-20 22:16:57 +0000 | [diff] [blame] | 569 | <computeroutput>VALGRIND_CHECK_VALUE_IS_DEFINED</computeroutput> to help |
| 570 | track these errors down -- work backwards from the point where the |
| 571 | uninitialised error occurs, checking suspect values until you find the |
| 572 | cause. This requires editing, compiling and re-running your program |
| 573 | multiple times, which is a pain, but still easier than debugging the |
| 574 | problem without Memcheck's help.</para> |
| 575 | |
| 576 | <para>As for eager reporting of copies of uninitialised memory values, |
| 577 | this has been suggested multiple times. Unfortunately, almost all |
sewardj | 3387889 | 2007-11-17 09:43:25 +0000 | [diff] [blame] | 578 | programs legitimately copy uninitialised memory values around (because |
njn | 3fdb362 | 2006-10-20 22:16:57 +0000 | [diff] [blame] | 579 | compilers pad structs to preserve alignment) and eager checking leads to |
| 580 | hundreds of false positives. Therefore Memcheck does not support eager |
| 581 | checking at this time.</para> |
| 582 | </answer> |
| 583 | </qandaentry> |
| 584 | |
| 585 | |
njn | bfc79f8 | 2009-01-06 05:54:45 +0000 | [diff] [blame] | 586 | <qandaentry id="faq.attach"> |
| 587 | <question id="q-attach"> |
| 588 | <para>Is it possible to attach Valgrind to a program that is already |
| 589 | running?</para> |
| 590 | </question> |
njn | 7441b99 | 2009-02-22 22:25:31 +0000 | [diff] [blame] | 591 | <answer id="a-attach"> |
njn | bfc79f8 | 2009-01-06 05:54:45 +0000 | [diff] [blame] | 592 | <para>No. The environment that Valgrind provides for running programs |
| 593 | is significantly different to that for normal programs, e.g. due to |
| 594 | different layout of memory. Therefore Valgrind has to have full control |
| 595 | from the very start.</para> |
| 596 | |
| 597 | <para>It is possible to achieve something like this by running your |
| 598 | program without any instrumentation (which involves a slow-down of about |
| 599 | 5x, less than that of most tools), and then adding instrumentation once |
| 600 | you get to a point of interest. Support for this must be provided by |
| 601 | the tool, however, and Callgrind is the only tool that currently has |
| 602 | such support. See the instructions on the |
| 603 | <computeroutput>callgrind_control</computeroutput> program for details. |
| 604 | </para> |
| 605 | </answer> |
| 606 | </qandaentry> |
| 607 | |
| 608 | |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 609 | </qandadiv> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 610 | |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 611 | |
| 612 | |
| 613 | <!-- Further Assistance --> |
| 614 | <qandadiv id="faq.help" xreflabel="How To Get Further Assistance"> |
| 615 | <title>How To Get Further Assistance</title> |
| 616 | |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 617 | <!-- WARNING: this file should not xref other parts of the docs, because it |
| 618 | is built standalone as FAQ.txt. That's why we link to, for example, the |
| 619 | online copy of the manual. --> |
| 620 | |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 621 | <qandaentry id="e-help"> |
de | bad57fc | 2005-12-03 22:33:29 +0000 | [diff] [blame] | 622 | <!-- <question><para/></question> --> |
| 623 | <answer id="a-help"> |
de | 97ab7e7 | 2005-11-27 18:19:40 +0000 | [diff] [blame] | 624 | <para>Read the appropriate section(s) of the |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 625 | <ulink url="&vg-docs-url;">Valgrind Documentation</ulink>.</para> |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 626 | |
| 627 | <para><ulink url="http://search.gmane.org">Search</ulink> the |
| 628 | <ulink url="http://news.gmane.org/gmane.comp.debugging.valgrind">valgrind-users</ulink> mailing list archives, using the group name |
| 629 | <computeroutput>gmane.comp.debugging.valgrind</computeroutput>.</para> |
| 630 | |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 631 | <para>If you think an answer in this FAQ is incomplete or inaccurate, please |
| 632 | e-mail <ulink url="mailto:&vg-vemail;">&vg-vemail;</ulink>.</para> |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 633 | |
njn | 25ac384 | 2009-08-07 02:58:11 +0000 | [diff] [blame] | 634 | <para>If you have tried all of these things and are still |
| 635 | stuck, you can try mailing the |
| 636 | <ulink url="&vg-lists-url;">valgrind-users mailing list</ulink>. |
| 637 | Note that an email has a better change of being answered usefully if it is |
| 638 | clearly written. Also remember that, despite the fact that most of the |
| 639 | community are very helpful and responsive to emailed questions, you are |
| 640 | probably requesting help from unpaid volunteers, so you have no guarantee |
| 641 | of receiving an answer.</para> |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 642 | </answer> |
| 643 | |
| 644 | </qandaentry> |
| 645 | </qandadiv> |
| 646 | |
| 647 | |
| 648 | <!-- FAQ ends here --> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 649 | </qandaset> |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 650 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 651 | |
| 652 | |
| 653 | <!-- template |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 654 | <qandadiv id="faq.installing" xreflabel="Installing"> |
| 655 | <title>Installing</title> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 656 | |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 657 | <qandaentry id="faq.problem"> |
| 658 | <question id="q-problem"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 659 | <para></para> |
| 660 | </question> |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 661 | <answer id="a-problem"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 662 | <para></para> |
| 663 | </answer> |
| 664 | </qandaentry> |
| 665 | |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 666 | </qandadiv> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 667 | --> |
| 668 | |
de | 9bec93c | 2005-11-25 05:36:48 +0000 | [diff] [blame] | 669 | </article> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 670 | |
| 671 | </book> |