Memory leak problem

[wlof]

Hello all,

My application produces plenty of memory leaks, and I'm unsure of how to track them down.

This app uses several different DLLs, the DLL projects and the app project are all in the same solution, and the following lines are included in the "stdafx.h" file from each project :

#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#endif

Despite this, I don't get any object information or line numbers in the output window, just the allocation order numbers. I tried breaking into them, but the problem is, they vary at each execution !

Am I missing something here?

Thanks for your help in advance!

[VictorN]

What kind of "memory leaks" messages do you get? Could you show?

[hoxsiew]

Basically, anytime you allocate heap memory (new, malloc()) you must have a corresponding release of that memory (delete, free()) or the runtime will flag a memory leak. Those should be easy to track. With DLLs OTOH, you need to be sure that you call any cleanup functions the DLL might have as internally there may be new's or malloc()'s that depend on cleanup functions to perform the delete's or free()'s. Be sure you know the API of the DLLs you are using.

[ahoodin]

Heres a little blast from the past. A little food for thought. You probably already get a dump from the debugger, but you can move the dump around in your source to try to pinpoint it.

CMemoryState oldMemState, newMemState, diffMemState;
//at start of leaky process
oldMemState.Checkpoint();
//at end of leaky process
newMemState.Checkpoint();
if( diffMemState.Difference( oldMemState, newMemState ) )
{
       TRACE( "Memory leaked!\n" );
        diffMemState.DumpStatistics();
	diffMemState.DumpAllObjectsSince();
}

[wlof]

What kind of "memory leaks" messages do you get? Could you show?

Of course. Have a look:

Detected memory leaks!
Dumping objects ->
{103801} normal block at 0x06A6D978, 48 bytes long.
 Data: < e        o A  ?> D0 65 03 10 CD CD CD CD F1 0C 6F CB 41 86 E8 3F 
{103788} normal block at 0x06A6D850, 48 bytes long.
 Data: < e        o A  ?> D0 65 03 10 CD CD CD CD F1 0C 6F CB 41 86 E8 3F 
Object dump complete.

A few remarks:
1. In my original post I said I had "plenty" of memory leaks, meanwhile I made a correction and now I only have two leaks left.
2. The allocation order numbers are in bold. With crtdbg.h, it is possible to break on a given allocation number. However, I can't exactly use this method because the allocation numbers vary (not by much, though) at every execution.
3. Using crtdbg.h and by calling "_CrtSetDbgFlag( _CRTDBG_MEM_ALLOC_DF | _CRTDBG_LEAK_CHECK_DF );" (I'm quoting from memory so the constants' names might be wrong), the output window should give me more info (like telling me the file and exact line number to the leaked memory allocation). However, as you can see, it doesn't. Why?

Basically, anytime you allocate heap memory (new, malloc()) you must have a corresponding release of that memory (delete, free()) or the runtime will flag a memory leak. Those should be easy to track. With DLLs OTOH, you need to be sure that you call any cleanup functions the DLL might have as internally there may be new's or malloc()'s that depend on cleanup functions to perform the delete's or free()'s. Be sure you know the API of the DLLs you are using.

Yes yes, I do know how leaks happen And I wrote the DLLs, so I'm pretty familiar with their APIs. But they're pretty complex and their memory allocation behavior is not always consistent. (Most of the time, the "who allocates is in charge of deallocating" rule applies, but sometimes it doesn't.)

As stated above, what I'd like to know is why crtdbg.h isn't doing its job of pinpointing the leaks within the solution.

Heres a little blast from the past. A little food for thought. You probably already get a dump from the debugger, but you can move the dump around in your source to try to pinpoint it.

Thank you. However, given the complexity of the project, it's going to be a pain in the a** to track it down this way, and I'd much rather use the facilities from crtdbg.h, if it's possible at all to make them work in my case.

[ahoodin]

Well you have added the defines, but perhaps you have not done the rest of the groundwork to make this work.

http://forums.microsoft.com/MSDN/Sho...14007&SiteID=1

http://support.microsoft.com/kb/140858

http://www.codeproject.com/tools/leakfinder.asp

[hmaturana]

You can Download and try purify I think is a divition of IBM. It works great.