Purify is a tool that can help you find logical errors in your program that lead to:

Purify works by instrumenting your code, adding runtime checks for bad memory accesses and storage leaks. When you run the instrumented program, a new purify window is opened; if your program performs any bad memory accesses, an error message will appear in the window. When your program finishes, a message telling you about storage leaks will appear. You can get more information about where the errors and/or storage leaks happen by clicking on the buttons to the left of the error messages.

How to Use Purify

To use purify, you must create an instrumented executable file. For example, if your program consists of two files named main.C and List.C, you could created an instrumented executable named a.out by typing:

(As usual, use the -o flag to produce an executable named something other than a.out.)

Once you have produced an instrumented executable, just run it in the usual way (by typing its name, and, if your program is designed to use them, the appropriate command-line arguments).

Don't be surprised if the instrumented executable runs much more slowly than the non-instrumented version; it may also be much larger than the non-instrumented version.


To illustrate using purify, consider the following program (with line numbers included for reference), which permits the user to demonstrate what purify does for a dereference of an uninitialized pointer, a NULL pointer, or a dangling pointer, and how it finds storage leaks:

Here's the way the purify window looks when you first run this program; note that in the top right of the window is says "0 errors, 0 leaked bytes". As your program runs, every time there is a bad memory access, the error count will be incremented. When the program finishes, the number of leaked bytes will be updated to tell you about your code's storage leaks.

Now assume that we respond "yes" to the first question ("test deref of uninitialized ptr (y for yes)?"), so that line 13 (p->id = 123;) is executed. This causes the following:

If we click on the little box to the left of the error message, new information about where the error occurred is given:

If we now click on the box to the left of "main", the actual code that caused the error is shown:

A similar sequence of events would occur if we answered yes to the second question in the program ("test deref of NULL pointer?"). Instead, let's go on to the third question ("test deref of freed pointer?"). Here's what happens if we answer yes to that question:

Clicking on the button to the left of the error message to get more information reveals:

Clicking on the button to the left of "main" to see the code that caused the error:

And now clicking on the button to the left of "main" further down (after the message "This block was allocated from:") to see the code that originally allocated the storage:

Finally, here's what happens if we say yes to the last question ("test storage leak?"; the program finishes, and purify reports that there were 4 leaked bytes:

Click to find out more about the storage leak:

Again for more information:

And one more time to see the actual code that allocated the memory that was never freed: