Addrcheck: a lightweight memory checker

5 Addrcheck: a lightweight memory checker

To use this skin, you must specify --skin=addrcheck on the Valgrind command line.

5.1 Kinds of bugs that Addrcheck can find

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:

Reading/writing memory after it has been free'd
Reading/writing off the end of malloc'd blocks
Reading/writing inappropriate areas on the stack
Memory leaks -- where pointers to malloc'd blocks are lost forever
Mismatched use of malloc/new/new [] vs free/delete/delete []
Some misuses of the POSIX pthreads API

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:

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.
Addrcheck accepts the same command-line flags as Memcheck, with the exception of ... (to be filled in).
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.
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.
Whether or not this has any effect in practice is unknown. I suspect not, but that is mere speculation at this stage.

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.

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.

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.

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 startkde). 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.

Addrcheck is a new experiment in the Valgrind world. We'd be interested to hear your feedback on it.