Getting Started with Rational Purify

Whether you're working in Visual C/C++ or Java, Rational^® Purify^® can save you time and improve the quality of your code.

For Visual C/C++ developers and testers

Run-time memory errors and leaks are among the most difficult errors to locate and the most important to correct. The symptoms of incorrect memory use are unpredictable and typically appear far from the cause of the error. The errors often remain undetected until triggered by some random event, so that a program can seem to work correctly when in fact it's only working by accident.

That's where Rational Purify can help you get ahead. Purify provides:

Fast, comprehensive run-time error detection for Visual C/C++ programs
Error checking even when the source is not available
Code-coverage data that pinpoints untested code

Purify automatically integrates into Microsoft Visual Studio and requires no special builds. You can use Purify without changing the way you work.

Find errors before they occur

Purify detects the following kinds of memory errors - and many others - before they actually occur, so you can resolve them before they do any damage:

Array bounds errors
Accesses through dangling pointers
Uninitialized memory reads
Memory allocation errors
Memory leaks

More information? For a complete list of the errors Purify detects, select Purify Messages in the Purify Help menu.

Check every component in your program

Software development today is component based. To deliver quality applications on time, you not only need to make sure your own code is error free, you also need a way to check the components your software uses - even when you don't have the source code. Errors that occur within a component may be the result of your code supplying the component with unexpected data; only Purify can detect such errors so that you can correct your use of the component and improve the reliability of your application.

Purify can check every component in your program, even in complex multi-threaded, multi-process applications, including:

DLLs, including Windows DLLs and Microsoft Foundation Class Library DLLs
Visual C/C++ components embedded within Visual Basic applications, Internet Explorer, Netscape Navigator, or any Microsoft Office application
Microsoft Excel and Microsoft Word plug-ins
COM-enabled applications using OLE and ActiveX controls

Purify also checks calls to Windows API functions, including GDI, Internet services, system registry, and COM and OLE interface API functions. It also validates parameters such as memory handles and pointers.

Look for errors in the right places

In addition to finding the critical errors that occur when you exercise your program, Purify can also tell you how thoroughly you've covered your program's code. Purify can collect coverage data automatically for every run, report exactly how much of your code you've checked, and identify untested lines and functions. Using this information you can be sure you're finding the errors in all your code, and that you won't be caught off-guard by undiscovered problems in lines or functions that you overlooked.

Purify is able to collect coverage data if Rational PureCoverage^® is installed on your system along with Purify.

More information? Look up coverage data in the Purify online Help index.

Don't wait--use Purify early and often

For maximum benefit, start using Purify as soon as your code is ready to run and continue using it regularly throughout your development cycle, especially for:

Code check-in: Reduce the risk that bugs in your code might impact other code modules.
Nightly builds: Incorporate Purify into your test harness to verify that modules work together, and to expose code dependencies and collisions. Collect coverage data for every run to make sure that your tests are exercising any code that has been added or modified.
Acceptance tests: Validate third-party code or code from other development groups before incorporating it into your application.

By using Purify early and often, you'll release clean, reliable products - on time.

For Java developers and testers

Java memory leaks?

Yes, there are Java memory leaks, and they can be serious.

The Java garbage collector automatically removes from memory objects that your program no longer needs, and so avoids most of the memory leaks that occur in other programming contexts. But Java applications can still consume more and more memory over time. The causes for this can be extremely difficult to track down. Purify makes it much easier to find and fix them.

There are two major categories of leaks in Java: object references that are no longer needed, and system resources that are not freed.

Object references that are no longer needed

Very often, Java code retains references to memory that it no longer needs, and this prevents the memory from being garbage collected. Java objects typically include references to other objects, so a single object can hold an entire tree of objects in memory. Problems occur, for example, when you:

add objects to arrays and forget about them.
do not release references to an object until the next time you use the object. A menu command, for example, can create an object and not release references to the object until the next time the command is called, which may never happen.
change an object's state while some references still reflect the old state. For example, when you store properties for a text file in an array and then store properties for a binary file, some fields, such as "number of characters," continue to hold memory that is no longer needed.
allow a reference to be pinned by a long-running thread. Setting the object reference to NULL does not help; the memory won't be garbage collected until the thread terminates or goes idle.

System resources that are not freed

Java methods can also allocate heap memory that exists outside of Java instances, such as resources for windows and bitmaps. Java often allocates these resources by calling C or C++ routines using Java Native Interface (JNI) calls.

How Purify can help

Purify helps you find these Java memory leaks by reporting the methods, classes, and objects that are responsible for monopolizing large chunks of memory that the garbage collector does not free.

Using the data Purify gathers, you can zero in on memory problems. Once you've located them, you can eliminate references to unneeded objects, or force garbage collections in key areas of your code. To free system resources, check your Java toolkit for help. For example, the dispose () method in Sun Microsystem's Abstract Windowing Toolkit (AWT) frees the system resources used by the Frame, Dialog, and Graphics classes.

Back| Next| Index| Table of contents