Software: Apache/2.0.54 (Fedora). PHP/5.0.4 

uname -a: Linux mina-info.me 2.6.17-1.2142_FC4smp #1 SMP Tue Jul 11 22:57:02 EDT 2006 i686 

uid=48(apache) gid=48(apache) groups=48(apache)
context=system_u:system_r:httpd_sys_script_t 

Safe-mode: OFF (not secure)

/usr/share/doc/valgrind-2.4.0/   drwxr-xr-x
Free 3.83 GB of 27.03 GB (14.17%)
                            Encoder    Tools    Proc.    FTP brute    Sec.    SQL    PHP-code    Update    Feedback    Self remove    Logout    

Viewing file:     ac_main.html (4.3 KB)      -rw-r--r--

5  Addrcheck: a lightweight memory checker

5.1  Kinds of bugs that Addrcheck can find

• 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 []
• Overlapping src and dst pointers in memcpy() and related functions
• 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 Addrcheck 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 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.

  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.