Please enable JavaScript to view this site.

Memory Validator Help

Navigation: Examples

Finding incorrect deallocations

Scroll Prev Top Next More


Finding incorrect deallocations


This example demonstrates detection of incorrect deallocation of allocated memory.


Examples where this can happen include the following, all of which Memory Validator can detect


an allocate with malloc() or calloc(), but then deallocated with delete or delete []

a reallocate with realloc() or _expand(), but then deallocated with delete or delete []

an allocate with new, but then deallocated with free()

an allocate with new, but then reallocated with realloc() or _expand()





Memory tab instructionStep Display... instructionStep ensure Memory Errors is checked


launch nativeExample.exe instructionStep wait until attaching is complete





menu Memory Errors menu instructionStep Incorrect Usage instructionStep Incorrect delete of memory instructionStep incurs a selection of deliberately incorrect deletion calls


menu File menu instructionStep Exit





wait for data transfer to complete


Memory tab instructionStep Refresh instructionStep shows the usual leaks and also the memory errors using the colour defined.





expand any of the items instructionStep shows the allocation and deallocation callstack locations


expand the topmost entry in any of those callstacks instructionStep shows the source code in CTeststakView::OnTestIncorrectdeleteofmemory()





Using delete and delete [ ]


Note the difference between delete and delete [] in the example above.


For simple types (char, int, etc) the difference is technical, rather than a memory leak.


For class objects, it's important and misuse can result in leaks. Undefined behaviour, including crashes, can result from using delete [] instead of delete.


seeAlsoThere is an archive available (at the time of writing) of an interesting discussion on delete and delete [] in C++externalLink



Mistakes that can happen


Sometimes Memory Validator will appear to get a type wrong or get the array classification wrong leading to an incorrect warning about an incorrect deallocation. Why does this happen?


There are two reasons this can happen.


1.You have specified that you are building with a particular version of Visual Studio, but you are actually building with a different version of Visual Studio. This will mean that for all CRT and MFC source file parsing Memory Validator will be looking at the wrong source files and wrong header files.


To fix this, change the version of Visual Studio in the Symbol Lookup settings to match the Visual Studio you are using.


2.The binary you are testing doesn't match the source code that is indicated by the debug information (or that is found by the source code locations on the File Locations settings).


To fix this, check the File Locations settings to ensure no incorrect paths are listed. Also check that the source code indicated by the debug information is the correct source code for the build you are testing.