The example program is run once and we use the Memory view to observe and investigate any double deallocations.
For each double deallocation, Memory Validator displays the allocation and deallocation locations.
•Memory tab Display... check Memory Errors if not already checked.
Settings menu Edit Settings... Data Collection Collect page check Memory Buffer detect enables the use of Uninitialized Data hooks
The target program will run slower than usual with this option as all functions related to strings and memory copying are monitored.
launch nativeExample.exe wait until attaching is complete
Memory Errors menu Buffer overrun submenu Overrun allocated memory allocates an array and the end of the array is deliberately overrun
In the Memory tab, the overrun corruption is detected and displayed
Memory Errors menu Buffer overrun submenu Underrun allocated memory allocates an array and the end of the array is deliberately underrun
In the Memory tab, the underrun corruption is detected and displayed
File menu Exit
wait for data transfer to complete
•Memory tab Refresh shows the usual leaks and also the two corrupted blocks using the colour defined.
•expand the most recent corruption shows the callstack at the point of corruption
•expand the topmost entry in the callstack shows the source at the corruption point in CTeststakView::OnBufferoverrunOverun()
•Make a note of the object address - e.g. in our example above 0x02137EC8
Query menu Query Address... enter the address in Address to search for Query shows all allocations including that address.
This should show a result that can be expanded to show the allocation location as the line above the corruption point we saw above.