Introduction

I would like share with you some experience in catching memory leaks.
In most case it is a long processe and required additional tools like PurifyNT or
BoundsChecker. Actually, catching simple memory leaks is possible by using the Microsoft
exported functionality.

In the enclosed example you will find an example with a memory leak. To see how it
works you should run program under the debugger. When the program finishes you will
see in the the 'Output' window, 'Debug' tab the following message.

In more advanced memory management cases you should look in the 'AfxMem.cpp' file
in MFC source directory. File contents plenty of memory management functions.

I have written a class CMemDiff that wraps CMemoryState
and helps track memory leaks. Just include the MemDiff files in your project.
A global variable of type CMemDiff is declared and it's constructor and
destructor will check the state of your memory at the start and end of your program
and report any leaks.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Sorry, this article was written 7 years ago. But 5 years ago I stopped developement and working as consultant. So, I wouldn't help you to fix it Probally we need to find work around for new version of MFC, Vista and x64 mix

i placed the #defines in stdafx.h, and most source files in my project compiled, but not the ones that included afxpriv.h--these files caused compile errors in malloc.h, for example, when it gets to calloc's prototype, it says:

So I tried to use the code but there is a problem I don't know to solve. I'm not using a file named stdfax.h. How do I have to implement tho code to use it.
I tried it like this.
//#include "stdafx.h"
//#include "CrtDbg.h"
#include "MemDiff.h"

The memory leaks report a number in curly braces, in the case of the example above it's {53}.

Somewhere in your progam as soon as possible put the command _CrtSetBreakAlloc(53). Obviously exchange that for the memory allocation number reported in your own memory leak. The program with then break execution at exactly the right spot for you to see where the memory was allocated

However, even when you have DEBUG_NEW defined you can occasionally still run into problems with the dump not telling you which line the errant block was allocated. Here's an enhancement to the tip for these situations.

Sometimes the number in curly braces varies each time you run your program, however carefully you try to follow the same path. Yet you only find the correct number after it's too late. This makes things a little hard!

My tip is that generally you should have a rough idea where the leak is. You can narrow it down to an extent by commenting out function calls etc., but when this breaks down you can use the following approach.

In my code, I'd worked out (by commenting it out) that the memory leak was always somewhere in the CGraphCtrl::SaveGraphSettings(pOpenFptr); call.

Here's how you get the debugger to break on the line responsible for creating the memory leak:

When I run it first time I comment out the _CrtSetBreakAlloc call and set a break point after the _CrtIsMemoryBlock call. I then note the allocation number in allocReqNum when the break point is hit.

When the program finishes I look at the memory leaks dump and note the number in curly braces. (If the number in curly braces is lower you need to look earlier in your code's execution!)

Now I can calculate the offset value to add to allocReqNum in the _CrtSetBreakAlloc call - in my example it's '1' - the difference between the number in curly braces in the memory dump and the value I got from akkicReqNum. So I uncomment out the _CrtSetBreakAlloc call and adjust the 'allocReqNum+1' to the correct offset number.

And, finally, now my program will break at the correct allocation point - the one which allocates the memory which is not freed by my program.

Hope this is all clear - if not let me know and I'll try to pen something a little fuller.

I must be slow - it's taken me years, plus the earlier tip, to think of this approach. But hopefully DEBUG_NEW will work for most situations.

My application is too big and it is not a good idea to look in everywhere , and from this application i found that it shows exact path where memory leak is occuring. but it does not show me. can you help me to detect memory leak where excatly it is occuring.

It is indeed a simpler way to detect memory leaks. But I don't have any idea about the following lines. I hope I have solved all the memory leak problem in my application. But still I am getting the following lines and getting error when I am closing my application. This would be a great help for me if you suggest me to analyse the following lines.

Some develop tools has their own memory management modules instead of the standard C/C++ libraries, for example, MSVC using it's debug version libraries to track the memory leaks and memory usage, AutoCAD can track the memory usage of DLLs(most are created by others) and found memory leaks.

Could you tell me how to implemente this feature in my own program or just some references ?