IBM Rational Purify

From Wikipedia, the free encyclopedia

This article may require cleanup to meet Wikipedia's quality standards.
Please improve this article if you can. (April 2008)

Purify
Developed by	IBM Rational
Latest release	7.0.0.0-010 (UNIX) 7.0.0.0-007 (Windows) / February 22, 2008
OS	Windows, Linux, Solaris, AIX, HP-UX
Genre	Profiler
License	Proprietary software
Website	ibm.com

See also purification for the sense of refining.

Purify is a memory debugger program used by software developers to detect memory access errors in programs, especially those written in C or C++. It was originally written by Reed Hastings of Pure Software. Pure Software later merged with Atria Software to form Pure Atria Software, which in turn was later acquired by Rational Software, which in turn was acquired by IBM. It is functionally similar to other memory debuggers, such as Insure++ and Valgrind.

Software Testing Portal

1 Overview
2 Differences with traditional debuggers
3 Supported platforms
4 See also
5 External links

[edit] 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). It is essential to note that 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 enormously 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.

[edit] Differences with traditional debuggers

The ability to detect non-fatal errors is a major distinction between Purify and similar programs from the usual debuggers. By contrast, debuggers generally only allow the programmer to quickly find the sources of fatal errors, such as a program crash due to reading a null pointer, but do not help to detect the non-fatal memory errors. Debuggers are useful for other things that Purify is not intended for, such as for stepping through the code line by line or examining the program's memory by hand at a particular moment of execution. In other words, these tools can complement each other for a skilled developer.

Purify also includes other functionality, such as high-performance watchpoints, which are of general use while using a debugger on one's code.

It is worth noting that using Purify makes the most sense in programming languages that leave memory management to the programmer. Hence, in Java, Lisp, or Visual Basic, for example, automatic memory management reduces occurrence of any memory leaks. These languages can however still have leaks; unnecessary references to objects will prevent the memory from being re-allocated. IBM has a product called Rational PurifyPlus to uncover these sorts of errors.

[edit] Supported platforms

***Supported C/C++ Platforms***
Operating System	Processor Architectures	Operating System versions	Compilers	Debuggers	Miscellaneous
Solaris
	Sun UltraSPARC	Solaris 10 base through 8/07 Solaris 9 base through 9/05 Solaris 8 base through 2/04	Sun C/C++ 5.3 through 5.9 GNU gcc/g++ 4.0 through 4.2 GNU gcc/g++ 3.0 through 3.4	Sun dbx 7.0 through 7.6 Sun dbx 6.2 GNU gdb 6.0 through 6.7	Solaris threads POSIX kernel threads Solaris ld 5.8 through 5.10
	AMD 64 Intel 64	Solaris 10 6/06 through 8/07	Sun C/C++ 5.8 through 5.9 GNU gcc/g++ 4.0 through 4.2 GNU gcc/g++ 3.4	Sun dbx 7.5 through 7.6 GNU gdb 6.0 through 6.7	POSIX kernel threads Solaris ld 5.10
HP-UX
	HP PA-RISC 2.0	HP-UX 11i v3 (11.31) HP-UX 11i v2 (11.23) HP-UX 11i (11.11) HP-UX 11.00	HP aC++ A.03.27 through A.03.73 HP aC++ A.03.74 (HP-UX 11i v3 only) HP C/ANSI C B.11.11.02 through B.11.11.16 GNU gcc/g++ 4.0 (32-bit only) GNU gcc/g++ 3.0 through 3.4	HP wdb 4.0 through 5.7 GNU gdb 6.0 through 6.7	POSIX kernel threads DCE threads HP-UX linker B.11.43 through B.11.58
	Intel Itanium 2 (single core)	HP-UX 11i v3 (11.31) Note: requires linker patch PHSS_359782 HP-UX 11i v2 (11.23) Note: requires September 2006 patch bundle and linker patch PHSS_35979	HP C/aC++ 6.10 through 6.16 GNU gcc/g++ 4.1	HP wdb 5.0 through 5.7	POSIX kernel threads HP-UX linker B.12.40 through B.12.48
Linux
	Intel IA-32	RHEL 5 (Server/Desktop) base through 5.1 RHEL 4 (AS/ES/WS) base through 4.6 RHEL 3 (AS/ES/WS) base through U9 SLES 10 base through SP1 SLES 9 base through SP4	GNU gcc/g++ 4.0 through 4.2 GNU gcc/g++ 3.2 through 3.4	GNU gdb 6.0 through 6.7	Native POSIX thread library (NPTL) GNU ld 2.13 through 2.17
	AMD64 Intel 64	RHEL 5 (Server/Desktop) base through 5.1 RHEL 4 (AS/ES/WS) base through 4.6 SLES 10 base through SP1 SLES 9 base through SP4	GNU gcc/g++ 4.0 through 4.2 GNU gcc/g++ 3.2 through 3.4	GNU gdb 6.0 through 6.7	Native POSIX thread library (NPTL) GNU ld 2.13 through 2.17
AIX
AIX	IBM POWER5	AIX 6.1 base AIX 5L v5.3 base through TL7 AIX 5L v5.2	IBM XL C/C++ 9.0 IBM XL C/C++ 8.0 IBM XL C/C++ 7.0 GNU gcc/g++ 3.4	IBM Debugger 6.0 IBM Debugger 5.0 GNU gdb 6.2	POSIX kernel threads AIX ld 5.2 through 6.1
Windows
Windows	Intel IA-32	Vista Business base Vista Enterprise base Vista Ultimate base XP Professional base through SP2 2000 Professional SP2 through SP4 2000 Server SP2 through SP4 2000 Advanced Server SP2 through SP4 Server 2003 Standard base through SP2 Server 2003 Enterprise base through SP2 Server 2003 R2 Standard base through SP2 Server 2003 R2 Enterprise base through SP2	Visual Studio 2005 Visual Studio .NET 2003 Visual Studio .NET Visual Studio 6.0	Visual Studio 2005 Visual Studio .NET 2003 Visual Studio .NET Visual Studio 6.0

***Supported Java/.NET Platforms***
Platform	Data Collection Type	Runtime Environment
Solaris
	Java data collection	Sun JRE 5.0 Sun JRE 1.4.1 Note: SPARC only
	C/C++ data collection via JNI	Sun JRE 1.4.2 Sun JRE 1.4.1 Sun JRE 1.3.1_U1
HP-UX
	Java data collection	Not supported
	C/C++ data collection via JNI	IBM JRE 1.4.2 IBM JRE 1.3.1 SP8, SP9 Sun JRE 1.4.2 Sun JRE 1.4.1 Sun JRE 1.3.1_U1
Linux
	Java data collection	Not supported
	C/C++ data collection via JNI	IBM JRE 1.4.2 IBM JRE 1.3.1 SP8, SP9 Sun JRE 1.4.2 Sun JRE 1.4.1 Sun JRE 1.3.1_U1
AIX
	Java data collection	Not supported
	C/C++ data collection via JNI	IBM JRE 1.4.2 IBM JRE 1.3.1 SP8, SP9 Sun JRE 1.4.2 Sun JRE 1.4.1 Sun JRE 1.3.1_U1
Windows
	Java data collection	IBM JRE 1.4.2 IBM JRE 5.0 SUN JRE 1.4.2 SUN JRE 1.5.0
	.NET data collection	.NET Framework 1.0 .NET Framework 1.1 base through SP1 .NET Framework 2.0 .NET Framework 3.0