In-Place Memory Leak Detection

Memory Validator provides several complementary methods for detecting memory leaks and handle leaks. The usual method is the end-to-end analysis of an application, watching all allocations and deallocations. Any allocations that are not deallocated by the end of the application’s lifetime are deemed to have leaked. 

An alternative to this is detecting memory leaks and handle leaks as an application executes. This is called in-place leak detection. When using in-place leak detection, Memory Validator provides you with a selection of options so that you can tailor the leak detection to your needs.

• Using In-Place Memory Leak Detection
• Using In-Place Memory Leak Detection with Watermarks

Sample Application

This tutorial will use the nativeExample.exe sample application to demonstrate memory leak detection. The nativeExample.exe application is shipped as a project with source code. The project can be found in the nativeExample directory in the same directory that Memory Validator was installed in. Please compile all configurations of the sample application before continuing the tutorial. The project file is nativeExample.dsp.

Using In-Place Memory Leak Detection

To use the in-place leak detection facilities, your application must be running.

• Start your program using Memory Validator’s launch program option.The launch application wizard displayed.

  Select [installdir]\nativeExample\debugNonLink\nativeExample.exe using the Browse… button. Accept all default settings and move through all pages of the wizard to the last page. Click the Start Application button.

• Use your program as normal. For the purposes of this tutorial, nativeExample.exe has some defects and has already leaked some memory. You can also generate more memory and handle leaks by using the many menu options. So we now have a situation in which the features of the leak detector can be demonstrated.
• To display the leak detection dialog, click on the leak detection icon.
  The leak detection dialog is displayed.
• The default settings on the dialog will detection memory leaks and handle leaks for all allocations that Memory Validator knows about at the time the Detect Leaks button is clicked. Any allocations that occur after (or are processed in the input queue) will not be checked. To check these you will need to perform another leak detection.To check for memory leaks and handle leaks in the application, click Detect Leaks.Memory Validator examines the list of allocations it knows about and prepares a list of allocations to check. A dialog is displayed informing you of the number of allocations that will be checked.
• Memory Validator checks the application for memory leaks and handle leaks. This can be a time consuming process as every pointer sized memory location in all the application’s heaps, all thread stacks, all DLL static data must be checked to ensure that it does reference any of the allocations Memory Validator is checking. The larger your application and the greater the amount of memory allocated, the longer the memory leak detect will take. The leak detection icon will be disabled for the duration of the leak detect.When Memory Validator has detected which objects have leaked, a statistics dialog is displayed.After the dialog is dismissed, the display on the Memory tab is updated to indicate which allocations have leaked. Note, that you must have the appropriate data display option enabled (i.e. CRT for C++ allocations, LocalAlloc for allocations with LocalAlloc(), etc).

  

• Leaks detected with the in-place memory leak detector are marked as potential leaks. The reason for this is that the pointer to the memory may have been encrypted by your application, or offset (as CStringData does), thus causing Memory Validator to incorrectly identify the allocation as leaked. When your application closes Memory Validator will update the status of any potentially leaked allocation to leaked if the allocation was leaked.Not all leaked allocations will be detected as leaked. This is because a pointer to the allocation is somewhere in the application’s memory. For example:

      CString    **csa;
      CString    *str;
  
      csa = new CString *[2];
      str = new CString();
      csa[0] = str
      csa[1] = NULL;
  

  In this example csa and str is leaked, but the CString object str is pointed to by the pointer in csa[0], Memory Validator will find this reference and thus csa will be marked potentially leaked whilst str will not be marked as potentially leaked.

Using In-Place Memory Leak Detection with Watermarks

To use the in-place leak detection facilities, your application must be running.

• • Start your program as described in the previous section.
  • Use your program as normal. For the purposes of this tutorial, nativeExample.exe has some defects and has already leaked some memory.We need to insert some watermarks so that we can demonstrate the use of watermarks. Insert a watermark after the most recent allocation by choosing Add watermark at most recent trace on the Managers menu.

    The insert watermark dialog is displayed. Type a meaningful name into the edit box to describe the watermark. For this demo, type beforeDemoLeak.

    

    Display the About box for the application, by choosing About nativeExample… on the Help menu. The example application leaks some memory when the About box is displayed.

    Insert another watermark after the most recent allocation by choosing Add watermark at most recent trace on the Managers menu. The insert watermark dialog is displayed. Type a meaningful name into the edit box to describe the watermark. For this demo, type afterDemoLeak.

    

    We now have some allocations with watermarks before and after the allocations.

  • To display the leak detection dialog, click on the leak detection icon.
    The leak detection dialog is displayed. We want to detect memory leaks that happened between the two watermarks we set up. Use the combo boxes to select the beforeDemoLeak and afterDemoLeak as appropriate.

To check for memory leaks and handle leaks in the application, click Detect Leaks.

Memory Validator examines the list of allocations it knows about and prepares a list of allocations to check for all allocations found between the specified watermarks. A dialog is displayed informing you of the number of allocations that will be checked.

• Memory Validator checks the application for memory leaks and handle leaks. This can be a time consuming process as every pointer sized memory location in all the application’s heaps, all thread stacks, all DLL static data must be checked to ensure that it does reference any of the allocations Memory Validator is checking. The larger your application and the greater the amount of memory allocated, the longer the memory leak detect will take. The leak detection icon will be disabled for the duration of the leak detect.When Memory Validator has detected which objects have leaked, a statistics dialog is displayed.

  After the dialog is dismissed, the display on the Memory tab is updated to indicate which allocations have leaked. Note, that you must have the appropriate data display option enabled (i.e. CRT for C++ allocations, LocalAlloc for allocations with LocalAlloc(), etc).