mirror of
https://github.com/Zenithsiz/ftmemsim-valgrind.git
synced 2026-02-06 03:23:58 +00:00
7a75a9f583
converted by Donna. Hooked it into the build system so they are only built when specifically asked for, and when doing "make dist". They're not perfect; in particular, there are the following problems: - The plain-text FAQ should be built from FAQ.xml, but this is not currently done. (The text FAQ has been left in for now.) - The PS/PDF building doesn't work -- it fails with an incomprehensible error message which I haven't yet deciphered. Nonetheless, I'm putting it in so others can see it. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3153
132 lines
4.9 KiB
XML
132 lines
4.9 KiB
XML
<?xml version="1.0"?> <!-- -*- sgml -*- -->
|
|
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
|
|
|
<chapter id="ac-manual" xreflabel="Addrcheck: a lightweight memory checker">
|
|
<title>Addrcheck: a lightweight memory checker</title>
|
|
|
|
<para>To use this tool, you must specify
|
|
<computeroutput>--tool=addrcheck</computeroutput> on the Valgrind
|
|
command line.</para>
|
|
|
|
<sect1>
|
|
<title>Kinds of bugs that Addrcheck can find</title>
|
|
|
|
<para>Addrcheck is a simplified version of the Memcheck tool
|
|
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.
|
|
Addrcheck can detect the following errors:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Reading/writing memory after it has been free'd</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Reading/writing off the end of malloc'd blocks</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Reading/writing inappropriate areas on the stack</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Memory leaks -- where pointers to malloc'd blocks are lost
|
|
forever</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Mismatched use of malloc/new/new [] vs free/delete/delete []</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Overlapping <computeroutput>src</computeroutput> and
|
|
<computeroutput>dst</computeroutput> pointers in
|
|
<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
|
|
advised to read <xref linkend="mc-manual.bugs"/>. Some important
|
|
points:</para>
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>Addrcheck is exactly like Memcheck, except that all the
|
|
value-definedness tracking machinery has been removed.
|
|
Therefore, the Memcheck documentation which discusses
|
|
definedess ("V-bits") is irrelevant. The stuff on
|
|
addressibility ("A-bits") is still relevant.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Addrcheck accepts the same command-line flags as
|
|
Memcheck, with the exception of ... (to be filled in).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Like Memcheck, Addrcheck will do memory leak checking
|
|
(internally, the same code does leak checking for both
|
|
tools). The only difference is how the two tools decide
|
|
which memory locations to consider when searching for
|
|
pointers to blocks. Memcheck will only consider 4-byte
|
|
aligned locations which are validly addressible and which
|
|
hold defined values. Addrcheck does not track definedness
|
|
and so cannot apply the last, "defined value",
|
|
criteria.</para>
|
|
|
|
<para>The result is that Addrcheck's leak checker may
|
|
"discover" pointers to blocks that Memcheck would not. So it
|
|
is possible that Memcheck could (correctly) conclude that a
|
|
block is leaked, yet Addrcheck would not conclude
|
|
that.</para>
|
|
|
|
<para>Whether or not this has any effect in practice is
|
|
unknown. I suspect not, but that is mere speculation at this
|
|
stage.</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
<para>Addrcheck is, therefore, a fine-grained address checker.
|
|
All it really does is check each memory reference to say whether
|
|
or not that location may validly be addressed. Addrcheck has a
|
|
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
|
|
down, compared to the tedious and often confusing search
|
|
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>
|