This is the first in a series of showcase reviews for our sponsors at CodeProject. These reviews are intended to provide you with information on products and services that we consider useful and of value to developers. They also allow you to discuss a product and interact with the manufacture or provider on a one-to-one basis.
Faster leak detection, better analysis.
A common problem in software development is the problem of detecting and fixing memory leaks, handle leaks and memory corruption. Performing this task without the aid of software tools can be a slow and time consuming task, often resulting in a lot of wasted time as avenues of investigation turn out to be dead ends and the search for the bug turns to a different area of the software. This problem gets harder to solve and harder to manage the larger the codebase being worked on.
Software tools are often employed to solve this problem. Selection of an appropriate software tool requires that the software tool provides various features.
- The software tool must not change the behaviour of the program being monitored.
- The software tool must have as little impact as possible on the performance (both speed and reliability) of the program being monitored.
- The software tool should provide many ways of interrogating the collected data as possible so that end users can look at a given problem from a number of angles.
- The software tool should be configurable so that the user has a choice of tailoring the behaviour of the tool. This allows users to maximise the speed at which data collection occurs whilst collecting the data required, without collecting data that is not needed to investigate the bug under investigation.
- If the program being monitored crashes, the software tool must not crash.
- The software tool must be reliable, and in the event that the software tool crashes, it must not crash the program being monitored.
- The software tool should also be capable of being used in a regression testing role, so that Quality Assurance departments can produce defect reports to direct software maintenance with a minimum of effort.
Memory Validator from Software Verification satisfies all of the criteria above.
Memory Validator is an automatic runtime error detection software tool for Windows applications. Memory Validator detects common problems associated with the use of dynamic memory allocation, Windows resources and handle management. Such problems include detecting memory leaks, resource leaks, handle leaks, incorrect allocations, buffer overruns, buffer under-runs, corrupted data, reference counting errors and un-initialised data. Memory Validator also provides support for detecting hotspots in the code where large amounts of memory or handles are allocated, reallocated or deallocated.
No special preparation of your program is required to use Memory Validator, simply use Memory Validator to launch your program and Memory Validator monitors your program's behaviour. You don't need to recompile or relink your program*. When your program performs an error, such as a double deallocation of memory or a buffer overwrite, Memory Validator tells you, showing you the error, the callstack for the error and the source code for the error. When you close your program, Memory Validator displays all the memory that has leaked. Each type of data displayed by Memory Validator is colour coded so that it is easy to identify. Powerful filtering mechanisms allow you to simplify the data that is collected and which data is displayed, so that you can concentrate on one particular error at a time.
Memory Validator provides support for more than just the C runtime heap, you can also monitor the Win32 HeapAlloc(), LocalAlloc(), GlobalAlloc() and VirtualAlloc() functions as well as custom heap managers that you have written yourself. If you are using a reference counting scheme in your software, you will have come across the problem of out-of-sync reference counts and trying to determine where the counts go out of sync. Memory Validator provides support for tracking this type of error.
There are occasions when the program you want to monitor is already running, or the program you want to monitor is started by another program. Say for example your program is a COM server that starts when a document is embedded in a web-page. Memory Validator provides support for attaching to your server at the time the web-page requests the COM object. This can be very useful for identifying double frees or memory leaks that only occur when the program is run as a COM server, and not as a standalone program. If the program you want to monitor is already running, you can attach to the program with Memory Validator and monitor the program from this point to the program's conclusion.
Powerful analysis capabilities allow you to find memory allocations by address, near an address, allocations that hold pointers that point to an address (useful for determining which objects are still referencing the memory allocation you are examining) and which allocations are pointed to by pointers in the allocation you are examining (useful for determining which objects this object is using). You can find allocations by object type, or by the full or partial name of a function in the callstack of the allocations, or the full or partial name of the function at the top of the callstack in the name. You can find memory allocations by filename, dll name, address range, page range, size range, allocation id number (debug only), allocation heap and allocation type (alloc, realloc, free). On the analysis page, you can select an allocation and then ask to see all related objects. Related objects are objects of the same type, objects previously allocated at this address (good for analysing what may have happened after a delete that happened too early), other objects of the same type, other objects allocated in the same class, file or module, and so forth. Based on the results of an analysis you can select one, some or all of the results, and then repeat the query on these objects to drill through an entire allocation chain, seeing which object was related to which. This functionality can be very useful in finding the cause of very subtle bugs, which are often caused hundreds or thousands of allocations before the bug results in a visible error in the program.
Memory Validator provides a visual presentation of the current number of allocations for each type of memory and the total number of active handles, a visual presentation of the virtual memory map, with different colours for each type of memory use. This view can be very useful for determining why requests for large blocks of memory fail. Your computer may report X bytes free, but when you look at the memory map, you can see the memory is in 20 different blocks that are not contiguous.
Memory Validator provides support for detecting memory allocation hotspots. Once identified, the memory allocation and deallocation strategy can be modified to improve the way in which memory is consumed, thus putting less strain on the memory allocator, and so improving program performance.
Memory Validator provides support for ensuring that all places in the program that can allocated, reallocate or deallocate memory have been visited during test sessions. This support is provided by the Coverage window. The quality assurance team can use these metrics to ensure that an application has been thoroughly tested prior to launch.
Memory Validator provides support for regression testing. Regression testing can be performed in attended and unattended modes. The regression testing allows you to compare a baseline session with a session representing the test just performed. When the two sessions are compared you can see where you are making improvements in memory leak fixing and where you are making regressions in memory leak detection. You can export these results in HTML and XML formats for further processing. Unattended regression testing allows you to run Memory Validator from a command line or batch file, start the program of your choice, monitor for memory leaks, compare the resulting session with a baseline for the test, produce the regression test report, save the session and export the results in HTML and XML. For Quality Assurance departments with can use the regression testing facilities with their overnight test suites to provide at-a-glance reports the next day of which parts of the software are improving or regressing. Feedback from this can dramatically improve the error detection rate from the overnight/rolling software build. The XML reports can be further processed to produce reports which can be put on the internal bug report web server, or forwarded to management for further action.
Memory Validator is very configurable. The default options allow you to make immediate progress in tackling common problems. For more comprehensive error detection you can enable more options, or just the options related to your bugs. For example, if you are interested in tracking handle leaks, you don't want your software tool to track memory leaks - that would be a waste of time and effort. With Memory Validator, you can do just that, turn off the memory leak tracking and only track the handles. Or, say you wanted to track memory leaks, but only for the HeapAlloc(), HeapReAlloc() and HeapFree() functions, and not the C runtime. Turn off the CRT tracking, turn on the HeapAlloc() tracking and start your program. These are just two examples of improving the speed and ease at which you can find bugs with Memory Validator. The configurability goes further than this, you can, if so desired, go down to the function level to specify which functions should and should not be monitored.
Typical users of Memory Validator are software developers that don't want to spend a long time trying to identify what is causing the memory corruption, double delete, or memory leaks in their program. Quality Assurance departments will be interested in the support for unattended regression testing. Management will be pleased that data exported from Memory Validator can be turned in reports indicating improvements and regressions thanks to the support for XML export.
For professionals wanting to identify and fix hard to find memory leaks, resource leaks and memory corruptions in a fast and efficient manner, Memory Validator is a must have tool.
For sales and information on Memory Validator click here.
* To use the Memory Validator API, you need to link to a specific library file. This change will be required once only. You may need to change compiler settings to use the dynamic C runtime library if you are using the static C runtime library. This change will be required once only.
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
