Overview
Purify allows dynamic verification, a process by which a program discovers errors that occur when the program runs, much like a debugger. Static verification or static code analysis, by contrast, involves detecting errors in the source code without ever compiling or running it, just by discovering logical inconsistencies. The type checking by a C compiler is an example of static verification.
When a program is linked with Purify, corrected verification code is automatically inserted into the executable by parsing and adding to the object code, including libraries. That way, if a memory error occurs, the program will print out the exact location of the error, the memory address involved, and other relevant information. Purify also detects memory leaks. By default, a leak report is generated at program exit but can also be generated by calling the Purify leak-detection API from within an instrumented application.
The errors that Purify discovers include array bounds reads and writes, trying to access unallocated memory, freeing unallocated memory (usually due to freeing the same memory for the second time), as well as memory leaks (allocated memory with no pointer reference). Most of these errors are not fatal (at least not at the site of the error), and often when just running the program there is no way to detect them, except by observing that something is wrong due to incorrect program behavior. Hence Purify helps by detecting these errors and telling the programmer exactly where they occur. Because Purify works by instrumenting all the object code, it detects errors that occur inside of third-party or operating system libraries. These errors are often caused by the programmer passing incorrect arguments to the library calls, or by misunderstandings about the protocols for freeing data structures used by the libraries. These are often the most difficult errors to find and fix.
Read more about this topic: IBM Rational Purify