The example application

 

The example application is a great way to explore the capabilities of Memory Validator.

 

The source and projects are included in the installation, but you'll need to build the example application yourself.

 

Once built, you can use nativeExample.exe in conjunction with Memory Validator to  

 

•monitor the behaviour of the application as you use it

 

•easily allocate memory and handles in many different ways

 

•observe deliberate memory and handle leaks
 

•cause and catch allocation and corruption errors

 

 

 

The example program can also be linked with the Memory Validator API to demonstrate API usage.

 

 

How to use these examples

 

The best way to understand how Memory Validator works is by example.

 

We recommend launching the example application from Memory Validator and observing how the menu actions affect captured information.

 

Examining the source code is the best way to see what's going on in the example application.

 

For convenience, we have provided the source locations where each menu action runs a test.

 

All test locations are in the CTeststakView class of nativeExample\TESTSVW.CPP

 

 

Menu options - a summary

 

•File exit only!
 

•Allocation typical memory allocation, reallocation and deallocation as well as memory leaks
 

•Memory Errors typical memory errors, such as buffer overrun, underrun, corruption, incorrect deallocation or reallocation, uninitialized data detection etc.
 

•Handles creation and deletion of Win32 resources. Thread creation and deletion to test cross thread allocation detection
 

•Trace send example TRACE messages to Memory Validator
 

•DLL explicit loading and unloading of DLLs
 

•Reporting call various API functions dumping leaking or uninitialised objects to a file, or to callback functions
 

•Help shows the about box (which allocates and leaks memory in the process)

 

We give more detail on the menu options in the example application, but the real detail of allocations and errors are in the source code itself.

 

The code is commented and some areas have detailed explanations of what is going on and the likely consequences so do take a look!

 

 

A warning!

 

Some of the tests deliberately corrupt the C runtime heap or the program stack, to demonstrate errors and Memory Validator's ability to detect them.

 

Generally, the example application is robust, but by the very nature of some of these examples, it's not unreasonable that it may crash on occasion!