Download Valgrind Documentation

Ptrcheck: an (experimental) pointer checking tool
• Coverage: the heap checking is relatively robust, requiring only that Ptrcheck can see calls to malloc/free et al. In
that sense it has debug-info requirements comparable with Memcheck, and is able to heap-check programs even
with no debugging information attached.
Stack/global checking is much more fragile. If a shared object does not have debug information attached, then
Ptrcheck will not be able to determine the bounds of any stack or global arrays defined within that shared object,
and so will not be able to check accesses to them. This is true even when those arrays are accessed from some
other shared object which was compiled with debug info.
At the moment Ptrcheck accepts objects lacking debuginfo without comment. This is dangerous as it causes
Ptrcheck to silently skip stack and global checking for such objects. It would be better to print a warning in such
circumstances.
• Coverage: Ptrcheck checks that the areas read or written by system calls do not overrun heap blocks.
doesn’t currently check them for overruns stack and global arrays. This would be easy to add.
But it
• Platforms: the stack/global checks won’t work properly on any PowerPC platforms, only on x86 and amd64
targets. That’s because the stack and global checking requires tracking function calls and exits reliably, and there’s
no obvious way to do it with the PPC ABIs. (cf with the x86 and amd64 ABIs this is relatively straightforward.)
• Robustness: related to the previous point. Function call/exit tracking for x86/amd64 is believed to work properly
even in the presence of longjmps within the same stack (although this has not been tested). However, code which
switches stacks is likely to cause breakage/chaos.
10.7. Still To Do: User Visible Functionality
• Extend system call checking to work on stack and global arrays.
• Print a warning if a shared object does not have debug info attached, or if, for whatever reason, debug info could
not be found, or read.
10.8. Still To Do: Implementation Tidying
Items marked CRITICAL are considered important for correctness: non-fixage of them is liable to lead to crashes or
assertion failures in real use.
• h_main.c: make N_FREED_SEGS command-line configurable.
• sg_main.c: Improve the performance of the stack / global checks by doing some up-front filtering to ignore
references in areas which "obviously" can’t be stack or globals.
This will require using information that
m_aspacemgr knows about the address space layout.
• h_main.c: get rid of the last_seg_added hack; add suitable plumbing to the core/tool interface to do this cleanly.
• h_main.c: move vast amounts of arch-dependent uglyness (get_IntRegInfo et al) to its own source file, a la
mc_machine.c.
• h_main.c: make the lossage-check stuff work again, as a way of doing quality assurance on the implementation.
• h_main.c: schemeEw_Atom: don’t generate a call to nonptr_or_unknown, this is really stupid, since it could be
done at translation time instead.
123