Debugging Dynamic Memory Usage Errors Using HP WDB (5900-1474; WDB 6.2; January 2011)

When to Suspect a Memory Leak?
You must suspect a memory leak in an application if the system runs out of swap space,
runs slower, or both. Memory leaks in an application increase the memory consumption
in an application. When the memory consumed by the application exceeds the resource
limits set by the kernel, the application fails with out-of-memory errors.
WDB enables you to detect out-of-memory conditions through runtime memory checking.
It also enables you to simulate out-of-memory conditions in an application to understand
application behavior under such conditions.
For information on how you can use WDB to simulate and detect out-of-memory conditions
in an application, see “Error Injection ” (page 29)
Types of Memory Leaks
Following are the types of memory leaks:
• Physical Leaks
A physical leak is a definite memory leak that occurs when an application loses all
handles, or all pointers to the allocated memory. If a valid pointer to a memory
block is absent, the elusive block of memory cannot be accessed or freed.
The handles to a memory block are typically lost under the following conditions:
◦ When an application overwrites a pointer that addresses a block of memory
with another address or data
◦ When a pointer variable goes out of scope
◦ When you free a structure or an array that has pointers which are not freed
When all handles to a block of memory are lost, it causes the block to be leaked.
Example 22 (page 100), Example 23 (page 102), and Example 24 (page 104) illustrate
how WDB detects memory leaks.
• Logical Leaks
A logical leak occurs when an application fails to optimally utilize the allocated
memory. In this case the allocated block of memory can still be accessed through a
pointer variable in the application.
Memory-Related Errors 9