How to Find A Memory Leak

To locate a memory leak, use the following process:

  1. Find the memory leak – Detect the presence of a memory leak in the system, given a particular reproducible sequence. You should be able to identify a specific process, but demonstrating an overall increase in committed system memory can qualify a memory leak as well.
  2. Isolate the memory leak – Determine the exact location in the source code where the un–freed allocation occurs. This can be a lengthy and tedious process, requiring specific tools, trial–and–error, and teamwork with the original author of the code.
  3. Fix the memory leak – After the first two steps are completed, this is easy. Fixing the memory leak usually involves adding some code to free the memory in the questionable code path.

The information that can be gathered in the first step becomes very helpful in completing step 2 and step 3.

Checking Memory

Basically, you can spot a memory leak when you detect an unexplained increase in either committed system memory—memory used by various applications—or in memory owned by a specific application. There are several approaches to take for checking the current memory situation, as follows:

  • Run the mi command. At the cesh prompt, type mi. This command generates a list of memory usages for each running application. In the Page Summary line specified for each application, you will see “r/w=” followed immediately by a number. This number indicates the number of allocated pages of memory for the indicated application. If this number is unexpected or has grown unexpectedly, you may have detected a memory leak in the indicated application.

Additional tools are available to snapshot the available memory, however, the approaches described above are recommended.

Remember that only unexpected increases in memory usage suggest a memory leak. For example, if you check memory in the Directions application after starting it for the first time and check it again after calculating a complex route, the memory page number increases. In this case, however, it is an expected increase because the Directions application needed to allocate some memory to calculate and store the route. The best method of determining whether or not a memory leak exists is to perform the same operation multiple times within a single application. An application must allocate temporary memory to perform a new task for the first time. Thereafter, the application can either re–use existing allocated memory or re–allocate the same amount of memory if it was already freed. In either case, the total number of allocated pages should not increase at a value greater than the previous increase.