Purify identifies true memory leaks by searching the entire address space looking for allocated memory to which there are no pointers. This technique enables Purify to detect a few leaked blocks out of the many blocks in use. This precision is critical, as a few bytes leaked can be easily missed amid the megabytes of allocated data in use. With Purify, even short test cases can be valuable in finding memory leaks.
Purify generates a Memory Leaked (MLK) summary when the program exits, that is, when the program goes through an exit(). A Purify memory leaked summary indicates the amount of memory leaked by the program during execution and identifies the origin of each leak by the functions that allocated the memory. If the program terminates because of a signal, Purify does not generate a report.
Purify finds memory leaks by searching for blocks that have no pointers to them. Since these blocks cannot be accessed, they are lost to the program and cannot be freed. Consider this example of a linked list:
At first, memory blocks A, B, C, and D all have references to them. A is referenced through the global variable pList, and B, C, and D through the pNext pointers.
Then, block C is removed from the list by setting the pNext pointer in B to point to D instead of C.
However, list block C is not freed. Unless there is another pointer to C, there is now no possible way to free C. It is a leaked memory block.
In the memory leaked message for this linked list, Purify shows
1 leaked block (C), 3 memory-in-use blocks (A, B, and D), and 4 allocated
blocks (A, B, C, and D).
Traditional leak detectors (like mprof) report the memory blocks that are not freed before the program exits by simply matching memory allocations and corresponding frees. This is misleading, since most of these memory blocks are not leaks. They are either permanently allocated memory, such as symbol tables, or memory that happens to be in use when the exit function is called. In this linked list example, a typical malloc-debug leak detector would report all four blocks (A, B, C, and D) as leaked. When no distinction is made between true memory leaks and memory in use, it is difficult to identify the real problem.
Purify also reports memory blocks that do not have pointers to their beginnings, but that do have a pointer to their interior. These blocks are probably leaks, because there is no pointer that can be used directly to free them. Sometimes, however, these blocks are still in use. Purify calls these Potential Leaks (PLK) to distinguish them from true Memory Leaks (MLK).
Notes:
Purify finds leaks of memory allocated using malloc and related functions. It cannot find memory leaks in programs that do not use malloc. Since the C++ new operation calls malloc, Purify finds memory leaks in C++ code.
By default,
Purify cannot find all leaks in memory blocks handled by custom memory
management routines that you create on top of malloc,
new, and delete.
For example, if you allocate a large block of memory and break it up into
smaller blocks, you can manage the allocation and freeing of that memory
on your own. Purify does not find leaks of those subdivided blocks.
For details on how to control Purify's operation while using custom
memory managers, click