A Bottom-Up Approach to Go after Leaks

Pattern to debug resource leaks

We have already described what leaks are in detail. We’ll now describe how we can diagnose them. Debugging leaks extends beyond simply identifying the allocation responsible for the leak. Our objective is to determine why the allocated resource is not being freed. This entails identifying the code path designed to release the allocation and comprehending the reasons for its omission.

A well-optimized resource management process ensures the release of all allocated or acquired resources within the code. Therefore, if a leak is detected, it suggests an imbalance between the number of “acquire” and “release” function calls.

To diagnose this, we must identify the “acquire” functions lacking corresponding “release” functions and investigate the factors contributing to the absence of release invocations. We will present a step-by-step strategy that starts from the lower levels of the software stack (the actual acquire or release function) to the higher levels. The higher levels include user action or use case that triggered the acquire or release function resulting in the leak.

The steps below are to be followed in the order in which they are listed. These steps are universally applicable, regardless of the programming language or platform being used. Each step serves a specific purpose, addressing queries about the leak or bug and, consequently, guiding us toward identifying the problematic code path. These steps can be effectively implemented even in customer environments where developers might face constraints in installing the necessary tools.

Step 0: Where is the problem?

To effectively debug a resource leak, the initial step involves identifying the layer where the problem originates. This entails determining whether the bug lies within the process itself or the underlying platform. For example, in a memory leak, the question to ask is whether the free function was called on a specific memory chunk, but the chunk is still not ...