Resources | Resources |



Analyzing the leak messages and the heap dump

  1. Open the heap dump CSV file in Microsoft Excel.
  2. Set up filters on the data and filter the data to only show the nodes in which the Owner field is set to the application under test.
  3. Sort the data smallest to largest based on the ts (timestamp) field.
  4. For each leaked heap allocation reported as leaked by Brew MP, search for the address of the allocation in the sorted heap dump.

    If the address shows up between tagged allocations of the following format, that is an indication that an object of the indicated ClassID has leaked from the location shown. For example, if the sorted heap dump shows the following tags:

    Address pLink3
    0x0721D4A0 CI | Start
    0x0721D800 ZTARemoteObject
    0x071B3220 NONAME
    0x071B3220 CI|0x1072401:0x1072401|.\AppUtils.c:379|0x71b3240|

    and the following heap allocation was reported as leaked by Brew MP when the application was closed:

    5/16/2011 4:50:32 PM AEEModule.c:266 - Warning 
    -- memory leak, freeing, 0x71B3220, NONAME, fs:/usermods/ImageApp, size 36

    This is an indication that an object of ClassID 0x1072401 (AEECLSID_CFileSystem2), which was created on line 379 of AppUtils.c, has been leaked. Further inspection and debugging of the application may be done to determine the reason this interface was not released and to fix the problem.

Note: After the memory and interface leaks are resolved, be sure to revert the changes made to AEEShell.h, AEEIShell.h, and AEEIEnv.h, and remove the ISHELL_OVERRIDE, IENV_OVERRIDE, and/or OVERRIDE_MOD1 preprocessor definitions from the application project file.