Ptrcheck is a Valgrind tool for finding overruns of heap, stack and global arrays. Its functionality overlaps somewhat with Memcheck's, but it is able to catch invalid accesses in a number of cases that Memcheck would miss. A detailed comparison against Memcheck is presented below.

Ptrcheck is composed of two almost completely independent tools that have been glued together. One part, in h_main.[ch], checks accesses through heap-derived pointers. The other part, in sg_main.[ch], checks accesses to stack and global arrays. The remaining files pc_{common,main}.[ch], provide common error-management and coordination functions, so as to make it appear as a single tool.

The heap-check part is an extensively-hacked (largely rewritten) version of the experimental "Annelid" tool developed and described by Nicholas Nethercote and Jeremy Fitzhardinge. The stack- and global- check part uses a heuristic approach derived from an observation about the likely forms of stack and global array accesses, and, as far as is known, is entirely novel.

The following end-user options are available:

In addition, the following debugging options are available for Ptrcheck:

Ptrcheck can check for invalid uses of heap pointers, including out of range accesses and accesses to freed memory. The mechanism is however completely different from Memcheck's, and the checking is more powerful.

For each pointer in the program, Ptrcheck keeps track of which heap block (if any) it was derived from. Then, when an access is made through that pointer, Ptrcheck compares the access address with the bounds of the associated block, and reports an error if the address is out of bounds, or if the block has been freed.

Of course it is rarely the case that one wants to access a block only at the exact address returned by malloc (et al). Ptrcheck understands that adding or subtracting offsets from a pointer to a block results in a pointer to the same block.

At a fundamental level, this scheme works because a correct program cannot make assumptions about the addresses returned by malloc. In particular it cannot make any assumptions about the differences in addresses returned by subsequent calls to malloc. Hence there are very few ways to take an address returned by malloc, modify it, and still have a valid address. In short, the only allowable operations are adding and subtracting other non-pointer values. Almost all other operations produce a value which cannot possibly be a valid pointer.

When a source file is compiled with -g, the compiler attaches DWARF3 debugging information which describes the location of all stack and global arrays in the file.

Checking of accesses to such arrays would then be relatively simple, if the compiler could also tell us which array (if any) each memory referencing instruction was supposed to access. Unfortunately the DWARF3 debugging format does not provide a way to represent such information, so we have to resort to a heuristic technique to approximate the same information. The key observation is that

if a memory referencing instruction accesses inside a stack or global array once, then it is highly likely to always access that same array

To see how this might be useful, consider the following buggy fragment:

   { int i, a[10];  // both are auto vars
     for (i = 0; i <= 10; i++)
        a[i] = 42;
   }

At run time we will know the precise address of a[] on the stack, and so we can observe that the first store resulting from a[i] = 42 writes a[], and we will (correctly) assume that that instruction is intended always to access a[]. Then, on the 11th iteration, it accesses somewhere else, possibly a different local, possibly an un-accounted for area of the stack (eg, spill slot), so Ptrcheck reports an error.

There is an important caveat.

Imagine a function such as memcpy, which is used to read and write many different areas of memory over the lifetime of the program. If we insist that the read and write instructions in its memory copying loop only ever access one particular stack or global variable, we will be flooded with errors resulting from calls to memcpy.

To avoid this problem, Ptrcheck instantiates fresh likely-target records for each entry to a function, and discards them on exit. This allows detection of cases where (eg) memcpy overflows its source or destination buffers for any specific call, but does not carry any restriction from one call to the next. Indeed, multiple threads may be multiple simultaneous calls to (eg) memcpy without mutual interference.

Memcheck does not do any access checks for stack or global arrays, so the presence of those in Ptrcheck is a straight win. (But see "Limitations" below).

Memcheck and Ptrcheck use different approaches for checking heap accesses. Memcheck maintains bitmaps telling it which areas of memory are accessible and which are not. If a memory access falls in an unaccessible area, it reports an error. By marking the 16 bytes before and after an allocated block unaccessible, Memcheck is able to detect small over- and underruns of the block. Similarly, by marking freed memory as unaccessible, Memcheck can detect all accesses to freed memory.

Memcheck's approach is simple. But it's also weak. It can't catch block overruns beyond 16 bytes. And, more generally, because it focusses only on the question "is the target address accessible", it fails to detect invalid accesses which just happen to fall within some other valid area. This is not improbable, especially in crowded areas of the process' address space.

Ptrcheck's approach is to keep track of pointers derived from heap blocks. It tracks pointers which are derived directly from calls to malloc et al, but also ones derived indirectly, by adding or subtracting offsets from the directly-derived pointers. When a pointer is finally used to access memory, Ptrcheck compares the access address with that of the block it was originally derived from, and reports an error if the access address is not within the block bounds.

Consequently Ptrcheck can detect any out of bounds access through a heap-derived pointer, no matter how far from the original block it is.

A second advantage is that Ptrcheck is better at detecting accesses to blocks freed very far in the past. Memcheck can detect these too, but only for blocks freed relatively recently. To detect accesses to a freed block, Memcheck must make it inaccessible, hence requiring a space overhead proportional to the size of the block. If the blocks are large, Memcheck will have to make them available for re-allocation relatively quickly, thereby losing the ability to detect invalid accesses to them.

By contrast, Ptrcheck has a constant per-block space requirement of four machine words, for detection of accesses to freed blocks. A freed block can be reallocated immediately, yet Ptrcheck can still detect all invalid accesses through any pointers derived from the old allocation, providing only that the four-word descriptor for the old allocation is stored. For example, on a 64-bit machine, to detect accesses in any of the most recently freed 10 million blocks, Ptrcheck will require only 320MB of extra storage. Achieving the same level of detection with Memcheck is close to impossible and would likely involve several gigabytes of extra storage.

In defense of Memcheck ...

Remember that Memcheck performs uninitialised value checking, which Ptrcheck does not. Memcheck has also benefitted from years of refinement, tuning, and experience with production-level usage, and so is much faster than Ptrcheck as it currently stands, as of October 2008.

Consequently it is recommended to first make your programs run Memcheck clean. Once that's done, try Ptrcheck to see if you can shake out any further heap, global or stack errors.

This is an experimental tool, which relies rather too heavily on some not-as-robust-as-I-would-like assumptions on the behaviour of correct programs. There are a number of limitations which you should be aware of.

Items marked CRITICAL are considered important for correctness: non-fixage of them is liable to lead to crashes or assertion failures in real use.