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.
| You must Sign In to use this message board. |
|
|
 |
|
|
|
|
|
I don't know the answer to this question.
#1) If you are referring to memory leaked in the browser used by the client visiting your website. The answer is no, since they are not using Memory Validator.
#2) If you are asking can you use Memory Validator with IIS. The answer is "Yes".
#3) If you are asking does Memory Validator supported managed applications (for example, using .Net), the answer is "No" as managed applications look after their own memory via garbage collection.
#4) If you are asking a different question, I don't understand what the question is. Please try phrasing the question differently. I mention this as someone has recently been asking us, via support, a similar, but very badly worded question, that we could not understand at all.
These questions should preferrably be directed to support@softwareverify.com, rather than asked in public forums.
Stephen Kellett
--
Memory Validator. Faster Leak Detection, Better Analysis.
http://www.softwareverify.com
http://www.objmedia.demon.co.uk/rsi.html
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
|
|
|
Peter Weyzen wrote:
How do you compare yourself to a package like SmartHeap?
The question is mis-characterized.
SmartHeap is a high performance memory allocator which out-performs many other allocators in multi-threaded scenarios.
SmartHeap is not a memory diagnostics tool. Memory Validator is. There are products that compete with SmartHeap - WinHeap comes to mind - created by some people in New Zealand. I have no experience of the product. There are also various free products. Depending on your application behaviour, SmartHeap, WinHeap or a free product may perform best.
The vendors of SmartHeap market a product known as HeapAgent.
There is no comparison between HeapAgent and Memory Validator - the HeapAgent UI is poor and provides very few user query functions - whereas MV provides more queries on collected data than any competing product. MV also provides support for custom allocators (no competing product provides this) and support for custom hooks so that you can monitor 3rd party APIs (no competing product provides this).
I recommend that you download both HeapAgent and Memory Validator and test them for yourself. The results will be very clear. If you have any questions, please email support@softwareverify.com.
Regards
Stephen Kellett
--
Memory Validator. Faster Leak Detection, Better Analysis.
http://www.softwareverify.com
http://www.objmedia.demon.co.uk/rsi.html
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
well, yes and no...
The debug SmartHeap is somewhat similar to your tools -- it does all kinds of things that you describe.
It notifies you of:
* memory leaks (including exactly who/where it was allocated file/lineno)
* heap corruption
* doubly deleted pointer
How does your product compare to the debug SmartHeap?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Peter Weyzen
Staff Engineer
"http://www.santacruznetworks.com">Santa Cruz Networks
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Peter Weyzen wrote:
How does your product compare to the debug SmartHeap?
I have not used SmartHeap. I didn't know it
could do the things you mention above. My comments were based on feedback from a relative of mine that has used SmartHeap (before we created Memory Validator).
Memory Validator does all those things and more. You can track
handle leaks, track the number of objects of a given type, support for custom allocators (build your own memory manager
and track the allocations from that using MV). Support for
custom hooks to track APIs written by 3rd parties (for example a database you are using). MV provides many query views for performing queries based on related allocations, address, page, object type etc.
You would be best advised to read the website pages about Memory Validator rather than read what I write here, which will not be as informative as the website.
If you just want the feature list:
http://www.softwareverify.com/memoryValidator/memval_feature.html
Please reply by email if you would like a more in-depth discussion.
Stephen Kellett
--
Memory Validator. Faster Leak Detection, Better Analysis.
http://www.softwareverify.com
http://www.objmedia.demon.co.uk/rsi.html
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Peter Weyzen wrote:
It notifies you of:
* memory leaks (including exactly who/where it was allocated file/lineno)
* heap corruption
* doubly deleted pointer
As a user of Memory Validator I agree with Stephen. Memory Validator does so much more than Smart Heap to detect leaks as memory validator deals with much more than the just heap allocations. In addition to the heap, resources, COM, Virtual memory and much much more are what is tracked by Memory Validator.
I would add that this is an apples and oranges comparison. Although they have some overlap they are truely two very different products.
John
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
I'm one of the WinHeap authors. The free version does not support heap checking as it only supports release builds. The Professional version includes considerable heap checking, including double deletes, buffer overruns, heap corruption etc. It does not attempt to trap memory leaks; for that we recommend a specialist product like Memory Validator.
Visit the WinHeap website for more information and a free download.
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
I am looking around to solve a problem I have with Movie Maker: I get abnormal program terminations with the error message Microsoft Visual C++ Runtime Library Runtime Error! I am too late for a restore with System Restore or Go Back, in case some recently installed software has anything to do with it.
Do you think this product would be able to determine where and why the problem occurs, and would that make a solution possible? Or do you have any other suggestions?
Unfortunately I know nothing about Visual C++, and it would be a pity if this would cause me to have to reinstall all my software on a fresh disk!
Hope you can help...
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Dear Ewout,
I doubt very much if any software tool will provide you with much information about a 3rd party software such as Movie Maker. There will be no source code to examine as and when an
error is identified. It sounds like there is a problem with
Movie Maker or one of the DLLs it uses (or a global hook that is loaded into Movie Maker may have the problem) that causes
a datastructure to become corrupted, thus leading to the error
message.
There is very little you can do about this, other than:
1) Report the error to the manufacturer of Movie Maker.
2) Try to get an update from the manufacturer (there may be one on their website).
3) Try uninstalling any software you think is responsible for loading incorrect DLL versions on to your machine.
4) Using system restore (I've found that very useful on my girlfriend's machine which gets all sorts of strange software loaded onto it, some of which crashes it - use System Restore, machine comes back to life, wonderful).
5) Full reinstalls (absolutely the last thing you want).
Sorry I can't be more helpful.
Stephen Kellett
--
Memory Validator. Faster Leak Detection, Better Analysis.
http://www.softwareverify.com
http://www.objmedia.demon.co.uk/rsi.html
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
I've done a speech application in Visual C++ and it build's ok but when I run it I get this error message:
Debug Error!
DAMAGE:after Normal block (#68) at 0x00374420.
Please Retry to debug the application.
And it gives me Cancel, Ignore or Retry options.
If I Retry in that MessageBox, I get the error:
unknown software exception (0x80000003) in direction 0x1021376f
I've installed SAPI 4 and TTS L&H 3000 and I don't know why I get this software exception.
How could I find where is the trouble?
Thank you in advance!
|
| Sign In·View Thread·PermaLink | 1.00/5 |
|
|
|
|
|
|
Yes, Memory Validator should help. This error occurs mostly when you use a pointer after the memory has been deallocated.
John
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Thank you 
It was only that I forgot add 1 when I asigned the Size for a SDATA variable. And the free command failed.
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
 My program is MFC program,when debug,there are the following messages:
****************************
Detected memory leaks!
Dumping objects ->
strcore.cpp(118) : {947} normal block at 0x00D74D70, 37 bytes long.
Data: 01 00 00 00 18 00 00 00 18 00 00 00 44 3A 5C 43
Object dump complete.
****************************
"strcore.cpp" is not my created file,how to find the position of memory leak in the program?
please give me some advice!
very very very thanks!
|
| Sign In·View Thread·PermaLink | 4.00/5 |
|
|
|
|
|
|
strcore.cpp is part of the implementation of CString. If you see
a memory leak with strcore.cpp it means you have leaked a CString.
Use Memory Validator with your application. It will show you the
location of any CString objects not de-allocated. You can then
decide the most appropriate place in your application to deallocate
these CStrings.
Stephen
|
| Sign In·View Thread·PermaLink | 2.00/5 |
|
|
|
|
|
|
|
|
|
my program is MFC program, when i use "exit()" exit application, object of class document,view and mainframe can not be free, for that reason,memory leak.
how to deal with it?
help me!
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
When you use exit() to end your MFC program, you prevent MFC from cleaning up properly, hence you will see leaked objects that are normally cleaned up.
A better way to close your MFC program would be send a
WM_CLOSE (or WM_QUIT?) message to the application's main window.
For example:
if (AfxGetMainWnd() != NULL)
AfxGetMainWnd()->PostMessage(WM_CLOSE, 0, 0);
// if here then no main window, can't send, so exit
exit(0);
Stephen
|
| Sign In·View Thread·PermaLink | 3.50/5 |
|
|
|
|
|
|
|
|
|
Just as a follow up, runtime C library functions (exit and many others) don't work that well in Win32 apps. Use MFC / Win32 APIs wherever possible, www.msdn.com is there to help.
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Hi,
I'm using Memory Validator 3.17 for evaluation purpose. I tried it with a few apps we developped and it worked very well!! But, for another application, I get a "memory could not be written" message just at the startup of the application (my application, not Validator). The message pops up just after the Validator initialization.
After that, the created process exists but no GUI is visible. If I start my application without Validator, everything is ok!
Do you have any idea of what is happening ??
Jean Bédard
Optifor Inc.
Canada
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Please contact support@softwareverify.com and we will be happy to provide support for this bug.
We do not provide support in open forums, they are not the best medium to discuss software support.
Stephen Kellett
Software Verification Support.
Stephen Kellett
--
Memory Validator. Faster Leak Detection, Better Analysis.
http://www.softwareverify.com
http://www.objmedia.demon.co.uk/rsi.html
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Stephen Kellett wrote:
We do not provide support in open forums, they are not the best medium to discuss software support.
I wish you had a forum for registered users. I have had very bad luck with a couple different MFC applications and the memory corruption detection that caused the application to crash at startup with memory validator running and ran fine without. But as I say that memory validator is much better and more stable than other products that I have tested(Purify,...). They failed to work on my pc most of the time with the most basic options selected.
John
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
John M. Drescher wrote:
I wish you had a forum for registered users. I have had very bad luck with a couple different MFC applications and the memory corruption detection that caused the application to crash at startup with memory validator running and ran fine without.
We have always planned to have a forum for users at some point. A forum on our website where we can monitor things easily and link replies to a knowledgebase is a completely different beast than fielding replies on a website such as CodeProject, no matter how much we like CodeProject. Even then, support is best performed by email - we don't believe discussing a particular customer's problems in public is good practice.
A forum where people could share their experiences, success, problems, tips for writing extension dlls, how-tos on subjects that we have not written tutorials for, this would be a great thing... and of course you get to let of steam on the rare occasion we do something you don't like
I expect any forums we provide will appear in early 2004, as we are busy working on new products for C++, Java and Python at present.
As for the Memory Corruption Detection crashes, I don't recollect any bugs having been submitted to us about these - please correct my memory if you have informed us of this bug. The Memory Corruption hooking is the most complicated part of Memory Validator, it rewrites just about the entire application to do that work. All the apps we have tested work OK, so until we find a binary that fails we can't identify why there is a failure.
If you need help please contact support@softwareverify.com, we are always pleased to help.
Stephen Kellett
--
Memory Validator. Faster Leak Detection, Better Analysis.
http://www.softwareverify.com
http://www.objmedia.demon.co.uk/rsi.html
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Thnaks for the reply.
Stephen Kellett wrote:
As for the Memory Corruption Detection crashes, I don't recollect any bugs having been submitted to us about these - please correct my memory if you have informed us of this bug. The Memory Corruption hooking is the most complicated part of Memory Validator, it rewrites just about the entire application to do that work. All the apps we have tested work OK, so until we find a binary that fails we can't identify why there is a failure.
I did not send an email because the program I was working on loads 3 of my dlls and it would not be simple to package the source for the code. Do you ever need the source?
Thanks Again,
John
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
