Please enable JavaScript to view this site.

Memory Validator Help

Navigation: The User Interface > Settings > Global Settings Dialog > Advanced > Instrumentation

Memory Corruption Detection

Scroll Prev Top Next More

The Memory Corruption Detection tab provides controls for detect memory corruption effectively while reducing the performance hit involved  


note The picture below shows this tab with the setting enabled, but the default setting is not to enable detection of memory corruption





How is memory corruption tested for?


Memory corruption is detected by visiting every memory allocation in the CRT heap and checking the entries in each location to see if the guard blocks on either side of the allocation are still valid.


In addition, any free blocks the CRT heap is still holding are also checked, to ensure that they have not been written to.


note Note that this only works for DEBUG builds as information in the DEBUG heap is required to enable this detection.


Detecting memory corruption


Memory Validator can detect memory corruption at the entry and exit points of functions in your application.


Detect Memory Corruption instructionStep enables detection


note Note that uninitialised data detection is disabled when this feature is enabled, and also callstacks for memory and handle allocations will not display correctly


The default setting is not to detect memory corruption as it can significantly affect performance speed.

hmtoggle_plus0 Why does detecting memory curruption affect performance so much? Enabling detecting memory corruption will cause a serious performance degradation for your application. This is because, in general, the longer your application executes, the more memory the application has used. This means the CRT heap has more allocations in it, and thus the task of checking the CRT heap for corruption takes longer. For small applications, or applications that allocate small amounts of memory the performance hit will not be too great. For other applications the performance hit will be quite high.



Once detection is enabled, the other settings help lower the impact on performance by reducing frequency of checks:


Check for memory corruption every N functions calls instructionStep reduces the performance hit by less frequent corruption checks


The default is every 500 calls, but you can change it in the range 1 to 100,000.


seeAlsoSee below for how to use this setting effectively with the memory corruption filters which are also described below.


Disable detection when errors found in heap instructionStep stops detecting more memory corruption errors once an error has been found.


The default is continue detection even after errors are found (i.e. the checkbox is off by default)


Check for memory corruption when function is...


...entered instructionStep perform checks before executing a function
...exited instructionStep perform checks after execution



Understanding the memory corruption results


When a memory corruption is detected, the main Memory tab shows the following items:


some data to indicate the memory allocations that have been corrupted (one line may relate to one or more corruptions)

a last known callstack prior to this corruption being detected

a callstack of the location when the corruption was detected


The two callstacks help to identify the area of the program between them as the potential cause of the memory corruption.


In the example below line id:482 shows that two objects of 10 bytes were corrupted, followed by a last known good and bad callstack for each corruption detected.


The known good callstack at line id:484 will show the last location in the program at which the CRT heap was known not to have been corrupted (or if already corrupted, then at least not corrupted any more!).


Finally, the known bad callstack at line id:485 is shown expanded and indicates the location at which the memory corruption was detected. Note that this is not necessarily the point at which memory was actually corrupted, as this depends on the value of N described above.




Because line id:482 related to two corruption detections, another good and bad callstack would be displayed below those shown here.



Memory corruption filters


Because of the performance hit of detecting memory corruption, it can be advisable to constrain detection to only part of an application.


To do this, you specify 'detectors' that switch the checking on and off.


A detector specifies a function name to which it applies and a status that applies when the program reaches the detector. When the program leaves the detector function, the previous status is applied.


Using the yellow check box, detectors can be disabled so as not to affect the detection status.


Memory Corruption Filters... instructionStep display the Memory Corruption Filters dialog (see below)





Using memory corruption filters


Detection of memory corruption is normally ON / OFF until modified by a detector instructionStep sets the default detection state

Add... instructionStep enter function, or class::method in column 1 instructionStep Click column 2 to add the state (default is Detect), double click to change it to Don't Detect.

Detectors are initially enabled. To disable a detector, use the yellow check box.


The function name can take the forms below - no need to specify return types or argument types

className::methodName        Matches class name and method name exactly

className::                        Any method in class className

::methodName                        Matches method methodName in any class

functionName                        Matches function name only


Remove instructionStep removes selected detectors from the list

Remove All instructionStep removes all detectors from the list


Enable All instructionStep enables all detectors

Disable All instructionStep disables all detectors

These don't affect the Detect status in column 2


note Note that data collection is still subject to the global data collection flags, so turn global data collection off also turns off memory corruption detection



Example of using memory corruption filters


Consider an application where only the myApp::sortThisData() function, and all functions called from it are of interest:


Choose Detection of memory corruption is normally OFF until modified by a detector instructionStep sets default checking state to OFF


Then Add... instructionStep enter myApp::sortThisData() in first column of the table instructionStep click in the second column to choose Detect


When the application reaches myApp::sortThisData() the detection of memory corruption is turned ON because of the Detect status.


The application runs as normal, and memory corruption is detected, until myApp::sortThisData() finishes executing.


At this point the previous detection status (OFF) is restored.



Using the filters and the 'check every N functions' settings  together


Setting N to 1 checks the CRT heap at every function entry and exit and corruption will be detected very close to the actual line of source code that caused the problem. However, the performance hit will be high - huge in fact,  for larger applications.


Setting N to, say 100, means the performance hit will be lower, but up to 100 functions may have been called between the memory corruption and its detection.


One strategy might be to start with a high value for N to get a feel for which part of the application is causing the corruption.


Then hone in on the corruption by using the memory corruption filters to focus on that part of the application, and decrease  N to 1 so that every function entry and exit is monitored inside the area covered by the filters.



Reset All - Resets all global settings, not just those on the current page.



Reset - Resets the settings on the current page.