Exercise 1.3: Analyzing leak candidates

Before you begin, you must complete Exercise 1.2: Capturing heap dumps.

In this exercise, you will first generate a list of objects (such as arrays, vectors, and sessions) that appear to be leaking. These are the "leak candidates." You will then analyze the list to identify any leaks.

Generating a list of leak candidates

To generate the list:

  1. Following the instructions in the Leak Candidates view, click the Analyze for Leaks toolbar button . The Select Leak Analysis Options dialog box opens.
  2. In the dialog box, make sure that the check boxes for your two heap dumps are checked.
    Note: The value for Threshold is set by default to 20. This means that only leak candidates with a Likelihood value of 20 or higher are displayed. (More information about Likelihood values is provided later in this Exercise.)
  3. Click OK to generate the list. The indicator at the lower-right corner of the Software Development platform reports that it is finding leak candidates.

An overview of the Leak Candidates view

When the process is complete, the Leak Candidates view displays a list of leak candidates.

Each candidate has a likelihood value between 100 and 1, with the most likely candidate having a value of 100. The other candidates are ranked accordingly, and are listed in order of descending likelihood. (The heap-comparison algorithm calculates likelihood values based on the size of the leak and on its growth during the interval between the two heap dumps.)

The Threshold value was set to 20 for this profiling run; any candidates with a Likelihood value of 19 or lower will not be displayed.

The view provides the following data for each leak candidate:

Analyzing and identifying the leak

To identify the leak:

  1. In the Leak Candidates view, look at the data for the leak candidate that has a likelihood of 100:
  2. Double-click the leak candidate. The Object Reference Graph view opens, and displays graphical data for the leak candidate. (Note that it might take some time to prepare the heap dump for display.)
  3. Examine the object reference graph. Note the following points:
  4. Pause your cursor over the path connecting the Object array and String, and read the tool-tip that is displayed: It shows a "Count" equal to the Number of Leaks displayed in the Leak Candidates view, so this is the collection of strings that has been identified as the leak.
  5. Note that both the Secondary and the Tertiary Queues are holding references to the Object array, but the Tertiary Queue isn't identified in the Leak Candidates view as leaking. There are several possible explanations for this:
  6. In the object reference graph, double-click the String object. The Object Details view opens. It displays all the details for the String object, including all objects that refer to it, and all objects to which it, in turn, refers. Note that, in the Object Details view, you can navigate up through referers by clicking one of them, or down through referees (objects to which the object refers) by clicking one of them.

What have you found out? You now know that the Secondary Queue is the leaking object, and that it is leaking because a Vector object is retaining references to many String objects.

Now you are ready to begin Exercise 1.4: Fixing the memory leak.

Terms of use | Feedback
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved.