mirror of
https://github.com/Zenithsiz/ftmemsim-valgrind.git
synced 2026-02-04 18:56:10 +00:00
0f6cf30022
Majorly improved. Still a lot to do, but the structure is better. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1324
102 lines
4.2 KiB
HTML
102 lines
4.2 KiB
HTML
<html>
|
|
<head>
|
|
<title>Addrcheck: a lightweight memory checker</title>
|
|
</head>
|
|
|
|
<body>
|
|
<a name="ac-top"></a>
|
|
<h2>5 <b>Addrcheck</b>: a lightweight memory checker</h2>
|
|
|
|
To use this skin, you must specify <code>--skin=addrcheck</code>
|
|
on the Valgrind command line.
|
|
|
|
<h3>5.1 Kinds of bugs that Addrcheck can find</h3>
|
|
|
|
Addrcheck is a simplified version of the Memcheck skin 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:
|
|
<ul>
|
|
<li>Reading/writing memory after it has been free'd</li>
|
|
<li>Reading/writing off the end of malloc'd blocks</li>
|
|
<li>Reading/writing inappropriate areas on the stack</li>
|
|
<li>Memory leaks -- where pointers to malloc'd blocks are lost
|
|
forever</li>
|
|
<li>Mismatched use of malloc/new/new [] vs free/delete/delete []</li>
|
|
<li>Some misuses of the POSIX pthreads API</li>
|
|
</ul>
|
|
<p>
|
|
|
|
<p>
|
|
Rather than duplicate much of the Memcheck docs here (a.k.a. since I
|
|
am a lazy b'stard), users of the Addrcheck skin are advised to read
|
|
the section on Memcheck. Some important points:
|
|
<ul>
|
|
<li>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.
|
|
<p>
|
|
<li>Addrcheck accepts the same command-line flags as Memcheck, with
|
|
the exception of ... (to be filled in).
|
|
<p>
|
|
<li>Like Memcheck, Addrcheck will do memory leak checking (internally,
|
|
the same code does leak checking for both skins). The only
|
|
difference is how the two skins 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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
Whether or not this has any effect in practice is unknown. I
|
|
suspect not, but that is mere speculation at this stage.
|
|
</ul>
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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 <code>startkde</code>). 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.
|
|
|
|
<p>
|
|
Addrcheck is a new experiment in the Valgrind world. We'd be
|
|
interested to hear your feedback on it.
|
|
|
|
</body>
|
|
</html>
|