Search for Memory Leaks

Applies to AQTime 8.81, last modified on January 18, 2022

To trace the memory usage in your application, use AQTime's Allocation profiler. This profiler monitors the application execution and tracks the allocations and deallocations of memory blocks as well as creation and deletion of objects in both managed and unmanaged code.

This topic provides a general scheme of finding memory leaks with AQTime’s Allocation profiler.

1. Profiling the Application

  1. Create a profiling project for your application.

  2. Select the Allocation profiler from the Profilers list and set up the profiling settings according to your needs.

  3. Specify the code to be profiled.

    The Allocation profiler traces creation and deletion of those objects whose class names are added to class-level areas in the Setup panel. Therefore, before you run the profiler, add the desired classes to class-level areas (see About Areas). Tracing allocations of memory blocks does not require any preparations to be made in the Setup panel.

    For more information, see Choosing What to Profile and When.

  4. Start profiling the application.

  5. Move the application to the state it is in before a possible memory leak can occur.

  6. Clear the profiling results by selecting the Run > Clear Results menu item.

  7. Perform actions that can lead to a leak and return the application to the state it is in step 4. If there are no leaks, all of the allocated memory should be released at this point.

  8. Get the current profiling results by clicking the Get Results button on the toolbar. The generated results allow you to see what objects currently exist in memory.

    AQTime also generates results after the application terminates. Results that were obtained after the application termination help you find memory leaks.

Note: If you are profiling a .NET application, you may want to force garbage collection before steps 5 and 8 to get clearer results. For information on how to do this, see Profiling .NET Applications - Overview.

2. Analyzing Profiling Results and Finding Memory Leaks

To find memory leaks, obtain the profiling results, select the desired result category (Classes Data or Objects) in the Explorer panel and analyze the results:

Searching for Memory Leaks - Classes Data Category

  1. The Report panel lists all classes whose instances were created during the application run. Examine the Live Count column that shows the number of object instances and memory blocks that currently exist in memory. If the value of this column is greater than zero, the given class has instances that had not been destroyed by the moment the results were generated.

  2. Filter or sort results on the Live Count column to quickly find classes whose instances were not destroyed.

  3. Examine the Live Size column to learn what amount of memory is occupied by these class instances and memory blocks.

  4. To find out where class instances were created:

    • Select the desired class in the Report panel and switch to the Call Tree panel. This panel allows you to view the call stack for all unrealeased objects of the selected class at once (note that this panel is empty if none of the stack areas is selected in the Collect Stack Information Pane).

    • Look for a routine that has a non-zero value for the Live Count column. This routine creates class instances that were not released.

Searching for Memory Leaks - Objects Category

  1. The Report panel lists memory blocks and class instances (that is, objects) that were allocated (created) and not destroyed during the application run.

  2. Find which routine allocated a memory block or created an object instance:

    • Click the desired block or object in the Report panel and switch to the Details panel.

    • Switch to the Creation Call Stack pane of the Details panel (note that this page is empty if none of the stack areas is selected in the Collect Stack Information Pane).

    • The Creation Call Stack pane displays the stack of function calls that led to the object creation (memory block allocation). The routine that created the object (allocated the memory block) occupies the topmost row.

    • To view the source code of a routine, double-click the routine in the call stack. AQTime will bring up the Editor panelpage that displays the routine's source codepage that displays the routine's source code and position the cursor on the first line of the routine’s source code.

      Note: If you profile a .NET application, you need to compile it with debug information so the Editor can show the application source code. See How AQTime Profilers Use Metadata and Debug Information.
Analyzing test results, you can find out exactly where leaked objects were created. However, AQTime cannot tell you when they must be destroyed as it completely depends on your application’s logic.

See Also

Memory and Resource Allocation Profiling
Best Practices and How to Tutorials
Viewing Call Stacks
Allocation Profiler - Overview

Highlight search results