<computeroutput>--tool=addrcheck</computeroutput> on the Valgrind
command line.</para>
+<para>Note: Addrcheck does not work in Valgrind 3.1.0. We may
+reinstate it in later releases.</para>
+
<sect1>
<title>Kinds of bugs that Addrcheck can find</title>
described in Section 3. It is identical in every way to
Memcheck, except for one important detail: it does not do the
undefined-value checks that Memcheck does. This means Addrcheck
-is about twice as fast as Memcheck, and uses less memory.
+is faster than Memcheck, and uses less memory.
Addrcheck can detect the following errors:</para>
<itemizedlist>
<computeroutput>memcpy()</computeroutput> and related
functions</para>
</listitem>
- <listitem>
- <para>Some misuses of the POSIX pthreads API</para>
- </listitem>
</itemizedlist>
-<para>Rather than duplicate much of the Memcheck docs here
-(a.k.a. since I am a lazy b'stard), users of Addrcheck are
+<para>Rather than duplicate much of the Memcheck docs here,
+users of Addrcheck are
advised to read <xref linkend="mc-manual.bugs"/>. Some important
points:</para>
memory overhead of one bit per byte of used address space. In
contrast, Memcheck has an overhead of nine bits per byte.</para>
-<para>Due to lazyness on the part of the implementor (Julian),
-error messages from Addrcheck do not distinguish reads from
-writes. So it will say, for example, "Invalid memory access of
-size 4", whereas Memcheck would have said whether the access is a
-read or a write. This could easily be remedied, if anyone is
-particularly bothered.</para>
-
<para>Addrcheck is quite pleasant to use. It's faster than
Memcheck, and the lack of valid-value checks has another side
effect: the errors it does report are relatively easy to track
sometimes needed to find the cause of uninitialised-value errors
reported by Memcheck.</para>
-<para>Because it is faster and lighter than Memcheck, our hope is
-that Addrcheck is more suitable for less-intrusive, larger scale
-testing than is viable with Memcheck. As of mid-November 2002,
-we have experimented with running the KDE-3.1 desktop on
-Addrcheck (the entire process tree, starting from
-<computeroutput>startkde</computeroutput>). Running on a 512MB,
-1.7 GHz P4, the result is nearly usable. The ultimate aim is
-that is fast and unintrusive enough that (eg) KDE sessions may be
-unintrusively monitored for addressing errors whilst people do
-real work with their KDE desktop.</para>
-
-<para>Addrcheck is a new experiment in the Valgrind world. We'd
-be interested to hear your feedback on it.</para>
-
</sect1>
</chapter>
</listitem>
</itemizedlist>
-<para>Note that older versions of Cachegrind used a log file
-named <computeroutput>cachegrind.out</computeroutput> (i.e. no
-<computeroutput>.pid</computeroutput> suffix). The suffix serves
+<para>The <computeroutput>.pid</computeroutput> suffix
+on the output file name
+serves
two purposes. Firstly, it means you don't have to rename old log
files that you don't want to overwrite. Secondly, and more
importantly, it allows correct profiling with the
which can but did not.</para>
<para>Sometimes only a small section of a source file is
-executed. To minimise uninteresting output, Valgrind only shows
+executed. To minimise uninteresting output, Cachegrind only shows
annotated lines and lines within a small distance of annotated
lines. Gaps are marked with the line numbers so you know which
part of a file the shown code comes from, eg:</para>
</listitem>
<listitem id="include">
- <para><computeroutput>-I=<dir>,
+ <para><computeroutput>-I<dir>,
--include=<dir></computeroutput> [default: empty
string]</para>
<para>Adds a directory to the list in which to search for
</listitem>
<listitem>
- <para>Valgrind's custom threads implementation will schedule
- threads differently to the standard one. This could warp the
- results for threaded programs.</para>
+ <para>Valgrind will schedule
+ threads differently from how they would be when running natively.
+ This could warp the results for threaded programs.</para>
</listitem>
<listitem>
- <para>The instructions <computeroutput>bts</computeroutput>,
+ <para>The x86/amd64 instructions <computeroutput>bts</computeroutput>,
<computeroutput>btr</computeroutput> and
<computeroutput>btc</computeroutput> will incorrectly be
counted as doing a data read if both the arguments are
</listitem>
<listitem>
- <para>FPU instructions with data sizes of 28 and 108 bytes
+ <para>x86/amd64 FPU instructions with data sizes of 28 and 108 bytes
(e.g. <computeroutput>fsave</computeroutput>) are treated as
though they only access 16 bytes. These instructions seem to
be rare so hopefully this won't affect accuracy much.</para>
<title>Valgrind FAQ</title>
<bookinfo>
<subtitle>Valgrind Frequently Asked Questions</subtitle>
- <releaseinfo>August 2005</releaseinfo>
+ <releaseinfo>November 2005</releaseinfo>
<author>
<surname>
<ulink url="http://www.valgrind.org/info/developers.html">Valgrind Developers</ulink>
<qandaentry id="faq.exit_errors">
<question>
<para>Programs run OK on Valgrind, but at exit produce a bunch
- of errors a bit like this:
-<programlisting>
-==20755== Invalid read of size 4
-==20755== at 0x40281C8A: _nl_unload_locale (loadlocale.c:238)
-==20755== by 0x4028179D: free_mem (findlocale.c:257)
-==20755== by 0x402E0962: __libc_freeres (set-freeres.c:34)
-==20755== by 0x40048DCC: vgPlain___libc_freeres_wrapper (vg_clientfuncs.c:585)
-==20755== Address 0x40CC304C is 8 bytes inside a block of size 380 free'd
-==20755== at 0x400484C9: free (vg_clientfuncs.c:180)
-==20755== by 0x40281CBA: _nl_unload_locale (loadlocale.c:246)
-==20755== by 0x40281218: free_mem (setlocale.c:461)
-==20755== by 0x402E0962: __libc_freeres (set-freeres.c:34)
-</programlisting>
-
- and then die with a segmentation fault.</para>
+ of errors involving <literal>__libc_freeres()</literal>
+ and then die with a segmentation fault.</para>
</question>
<answer>
<para>When the program exits, Valgrind runs the procedure
<title>Valgrind behaves unexpectedly</title>
<qandaset id="qset.unexpected">
-<qandaentry id="faq.slowthread">
- <question>
- <para>My threaded server process runs unbelievably slowly on
- Valgrind. So slowly, in fact, that at first I thought it had
- completely locked up.</para>
- </question>
- <answer>
- <para>We are not completely sure about this, but one
- possibility is that laptops with power management fool
- Valgrind's timekeeping mechanism, which is (somewhat in error)
- based on the x86 RDTSC instruction. A "fix" which is claimed
- to work is to run some other cpu-intensive process at the same
- time, so that the laptop's power-management clock-slowing does
- not kick in. We would be interested in hearing more feedback
- on this.</para>
-
- <para>Another possible cause is that versions prior to 1.9.6
- did not support threading on glibc 2.3.X systems well.
- Hopefully the situation is much improved with 1.9.6 and later
- versions.</para>
- </answer>
-</qandaentry>
-
-
<qandaentry id="faq.reports">
<question>
<para>My program uses the C++ STL and string classes. Valgrind
<para>Helgrind is a Valgrind tool for detecting data races in C
and C++ programs that use the Pthreads library.</para>
-<para>To use this tool, you specify
+<para>Note: Helgrind does not work in Valgrind 3.1.0. We hope
+to reinstate in version 3.2.0.</para>
+
+<para>To use this tool, you must specify
<computeroutput>--tool=helgrind</computeroutput> on the Valgrind
command line.</para>
<chapter id="lk-manual" xreflabel="Lackey">
<title>Lackey: a very simple profiler</title>
+
+<para>To use this tool, you must specify
+<computeroutput>--tool=lackey</computeroutput> on the Valgrind
+command line.</para>
+
<para>Lackey is a simple Valgrind tool that does some basic
program measurement. It adds quite a lot of simple
instrumentation to the program's code. It is primarily intended
<itemizedlist>
<listitem><para>It can speed up your program -- a smaller
- program will interact better with your machine's caches,
- avoid paging, and so on.</para></listitem>
+ program will interact better with your machine's caches and
+ avoid paging.</para></listitem>
<listitem><para>If your program uses lots of memory, it will
reduce the chance that it exhausts your machine's swap
<computeroutput>hp2ps</computeroutput> to convert the raw data
into the PostScript graph. It's distributed with Massif, but
came originally from the
-<ulink url="http://haskell.cs.yale.edu/ghc/">Glasgow Haskell
+<ulink url="http://www.haskell.org/ghc/">Glasgow Haskell
Compiler</ulink>. You shouldn't need to worry about this at all.
However, if the graph creation fails for any reason, Massif will
tell you, and will leave behind a file named
<chapter id="mc-manual" xreflabel="Memcheck: a heavyweight memory checker">
<title>Memcheck: a heavyweight memory checker</title>
-<para>To use this tool, you must specify
+<para>To use this tool, you may specify
<computeroutput>--tool=memcheck</computeroutput> on the Valgrind
-command line.</para>
+command line. You don't have to, though, since Memcheck is the default
+tool.</para>
<sect1 id="mc-manual.bugs"
<literal>C</literal>) or delete (<literal>C++</literal>),
that memory is not immediately made available for
re-allocation. Instead it is marked inaccessible and placed
- in a queue of freed blocks. The purpose is to delay the
+ in a queue of freed blocks. The purpose is to defer
+ as long as possible
+ the
point at which freed-up memory comes back into circulation.
This increases the chance that Memcheck will be able to
detect invalid accesses to blocks for some significant period
of time after they have been freed.</para>
<para>This flag specifies the maximum total size, in bytes,
- of the blocks in the queue. The default value is one million
+ of the blocks in the queue. The default value is five million
bytes. Increasing this increases the total amount of memory
used by Memcheck but may detect invalid uses of freed blocks
which would otherwise go undetected.</para>
distance below the stack pointer are due to bugs in gcc
2.96, and does not report them. The "small distance" is 256
bytes by default. Note that gcc 2.96 is the default compiler
- on some popular Linux distributions (RedHat 7.X, Mandrake)
- and so you may well need to use this flag. Do not use it if
+ on some older Linux distributions (RedHat 7.X)
+ and so you may need to use this flag. Do not use it if
you do not have to, as it can cause real errors to be
- overlooked. Another option is to use a gcc/g++ which does
- not generate accesses below the stack pointer. 2.95.3 seems
- to be a good choice in this respect.</para>
- <para>Unfortunately (27 Feb 02) it looks like g++ 3.0.4 has a
- similar bug, so you may need to issue this flag if you use
- 3.0.4. A while later (early Apr 02) this is confirmed as a
- scheduling bug in g++-3.0.4.</para>
+ overlooked. A better alternative is to use a more recent gcc/g++ in which
+ this bug is fixed.</para>
</listitem>
<listitem id="partial">
<title>Explanation of error messages from Memcheck</title>
<para>Despite considerable sophistication under the hood,
-Memcheck can only really detect two kinds of errors, use of
+Memcheck can only really detect two kinds of errors: use of
illegal addresses, and use of undefined values. Nevertheless,
this is enough to help you discover all sorts of
memory-management nasties in your code. This section presents a
is not a valid stack address -- it is below the stack pointer
and that isn't allowed. In this
particular case it's probably caused by gcc generating invalid
-code, a known bug in various versions of gcc.</para>
+code, a known bug in some ancient versions of gcc.</para>
<para>Note that Memcheck only tells you that your program is
about to access memory at an illegal address. It can't stop the
}]]></programlisting>
<para>It is important to understand that your program can copy
-around junk (uninitialised) data to its heart's content.
+around junk (uninitialised) data as much as it likes.
Memcheck observes this and keeps track of the data, but does not
complain. A complaint is issued only when your program attempts
to make use of uninitialised data. In this example, x is
by 0x4C21788F: OLEFilter::convert(QCString const &) (olefilter.cc:272)
]]></programlisting>
-<para>The following was told to me be the KDE 3 developers. I
-didn't know any of it myself. They also implemented the check
-itself.</para>
-
<para>In <literal>C++</literal> it's important to deallocate
memory in a way compatible with how it was allocated. The deal
is:</para>
know this".</para>
<para>Pascal Massimino adds the following clarification:
-<computeroutput>delete[]</computeroutput> must be called
-associated with a <computeroutput>new[]</computeroutput> because
+<computeroutput>delete[]</computeroutput> must be used for
+objects allocated by <computeroutput>new[]</computeroutput> because
the compiler stores the size of the array and the
pointer-to-member to the destructor of the array's content just
before the pointer actually returned. This implies a
<title>Passing system call parameters with inadequate read/write
permissions</title>
-<para>Memcheck checks all parameters to system calls, i.e:
+<para>Memcheck checks all parameters to system calls:
<itemizedlist>
<listitem><para>It checks all the direct parameters
themselves.</para></listitem>
<listitem>
<para>Still reachable: A pointer to the start
of the block is found. This usually indicates programming
- sloppiness; since the block is still pointed at, the
- programmer could, at least in principle, free'd it before
+ sloppiness. Since the block is still pointed at, the
+ programmer could, at least in principle, free it before
program exit. Because these are very common and arguably
not a problem, Memcheck won't report such blocks unless
<computeroutput>--show-reachable=yes</computeroutput> is
by 0x........: mk (leak-tree.c:11)
by 0x........: main (leak-tree.c:39)
-88 (8 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 13 of 14
+88 (8 direct, 80 indirect) bytes in 1 blocks are definitely lost
+ in loss record 13 of 14
at 0x........: malloc (vg_replace_malloc.c:...)
by 0x........: mk (leak-tree.c:11)
by 0x........: main (leak-tree.c:25)
blocks. Both kinds of leak are bad.</para>
<para>The precise area of memory in which Memcheck searches for
-pointers is: all naturally-aligned 4-byte words for which all A
+pointers is: all naturally-aligned machine-word-sized words for which all A
bits indicate addressibility and all V bits indicated that the
stored value is actually valid.</para>
<para>In short, each bit in the system has an associated V bit,
which follows it around everywhere, even inside the CPU. Yes,
-all the CPU's registers (integer, floating point, and condition
+all the CPU's registers (integer, floating point, vector and condition
registers) have their own V bit vectors.</para>
<para>Copying values around does not cause Memcheck to check for,
<listitem>
<para>When doing system calls, A bits are changed
appropriately. For example, mmap() magically makes files
- appear in the process's address space, so the A bits must be
+ appear in the process' address space, so the A bits must be
updated if mmap() succeeds.</para>
</listitem>
<para>Memcheck intercepts calls to malloc, calloc, realloc,
-valloc, memalign, free, new and delete. The behaviour you get
+valloc, memalign, free, new, new[], delete and delete[].
+The behaviour you get
is:</para>
<itemizedlist>
<listitem>
- <para>malloc/new: the returned memory is marked as
+ <para>malloc/new/new[]: the returned memory is marked as
addressible but not having valid values. This means you have
to write on it before you can read it.</para>
</listitem>
</listitem>
<listitem>
- <para>free/delete: you may only pass to free a pointer
- previously issued to you by malloc/calloc/realloc, or the
- value NULL. Otherwise, Valgrind complains. If the pointer is
+ <para>free/delete/delete[]: you may only pass to these
+ functions a pointer
+ previously issued to you by the corresponding allocation function.
+ Otherwise, Valgrind complains. If the pointer is
indeed valid, Valgrind marks the entire area it points at as
unaddressible, and places the block in the
freed-blocks-queue. The aim is to defer as long as possible
you to get and set the V (validity) bits for an address
range. You should probably only set V bits that you have got
with <computeroutput>VALGRIND_GET_VBITS</computeroutput>.
- Only for those who really know what they are doing.</para>
+ Only for those who really know what they are doing. Note: currently
+ disabled in Valgrind 3.1.0.</para>
</listitem>
</itemizedlist>
projects / thirdparty / valgrind.git / commitdiff
