The Allocation profiler detects memory leaks that occur in your application during profiling. For each leak detected, the profiler collects information on the call stack, that is, a sequence of function calls that led to creation of an object or allocation of a memory block that was not released. (The profiler reports the creation call stack; it is unable to determine and report where an object must be released, as this depends on your application’s algorithms.) Call stacks help you understand where objects were created or where memory blocks were allocated and decide where your program should release them.
The Allocation profiler organizes results into two categories: Classes Data and Objects. The Classes Data provides information on classes and types whose instances exist in memory. The Objects category provides information on individual instances (see Allocation Profiler Panels Reference). The way you view the call stack data depends on which of these two categories are active. For more information, see the following sections:
If the Classes Data category is selected, the call stack information is shown in the Call Tree panel. The panel displays call routes in a tree-like structure for the class that is currently selected in the Report panel. When you choose another class in the Report panel, the Call Tree automatically updates.
Viewing calls in a tree helps you easily observe all the call routes and single out those that require your attention first of all. In the tree you can also easily see how many class instances existed in memory after a certain routine was called.
To view the call stack, follow these steps:
Select the Classes Data category in the Explorer panel.
Check the View Allocation Paths in Call Tree button on the toolbar of the Report panel. This will command AQTime to display calls data in the Call Tree panel.
In the Report panel, select a class whose Live Count column value is non-zero. This means that the class instances currently exist in memory.
Switch to the Call Tree panel, expand the tree nodes and search for routines whose Live Count value is greater than 0. If the Live Count value of some routine is greater than 0, this means that the routine creates class instances (or allocates memory blocks). If the value is 0, this means the routine does not create leaked class instances (does not allocate memory blocks).
The Live Count With Children value specifies the sum of leaks “produced” by the routine and the leaks the routine “got” from child routines.
If the Objects result category is selected, the Report panel displays a list of objects (or memory blocks) that exist in memory and the call stack information for the selected object (or memory block) shown in the Details panel. That is, when the Objects category is active, you can explore call stacks for individual leaks.
Select the Objects category in the Explorer panel.
The Creation Call Stack page of the Details panel will display the stack of function calls that led to creation of the object. The topmost routine in the stack is the one that created the object (or allocated the memory block).
When profiling an application at line level, you can view the routine’s source code. To do this, double-click this routine in the Details panel. AQTime will bring up the Editor panel and position the cursor on the routine’s code in it. In order for AQTime to get the source code, the following requirements should be met:
The source file of the routine must be specified in the Project Search Directories dialog.
You need to compile the application with debug information. See How AQTime Profilers Use Metadata and Debug Information.
You cannot view a stack if none of the stack areas is selected in the Collect Stack Information Pane.
If you have several unreleased instances of the same class (if the Classes Data category is selected, the Live Count column of the Report panel specifies the number of currently existing instances), it is convenient to explore the call stack when the Classes Data category is selected. In this case, the Call Tree panel displays the creation call stack for all unreleased objects at once, and you do not have to explore the call stack for each unreleased object separately. This lets you analyze test results quickly.
If you need to analyze creation of individual instances separately, use the Objects category of the profiling results. When you select the Objects category in the Explorer panel, the Report panel displays a list of class instances (objects) and memory blocks that exist in the memory. To determine where an object was created, select it in the Report panel and switch to the Details panel. The Creation Call Stack page of the Details panel will show the call stack for this unreleased object. For more information, see Allocation Profiler Panels Reference.
Using the information provided by AQTime panels, you can find out exactly where the leaked objects were created. However, AQTime cannot indicate the place where these objects must be released as it depends on your application’s logic.