Memory Leak: Cannot Break Memory Allocation Number

Question

I am trying to find a memory leak problem.

My project is an ATL based interactive project that uses DirectShow and the standard library.

I get a total of 45 memory leaks in my program, all 24 bytes each.

I have # define'd _CRTDBG_MAP_ALLOC etc. in my stdafx.h along with DEBUG_NEW to get the file and line numbers for each memory leak.

However, line numbers are not printed. Memory blocks are “normal” blocks and look like this:

{180} normal block at 0x003E6008, 24 bytes long. Data: < > _> > W > A0 AE 3E 00 B0 5F 3E 00 A0 AE 3E 00 57 00 00 00 

I tried adding the following line to the beginning of _tWinMain ()

 _CrtSetBreakAlloc(180); 

to break the selection, but the debugger will not break at all.

Can someone give me an idea of ​​how I could track elusive memory leaks?

Finally, here is my _tWinMain () - I call _CrtDumpMemoryLeaks () just before exiting.

 int WINAPI _tWinMain(HINSTANCE hInstance, HINSTANCE /*hPrevInstance*/, LPTSTR lpstrCmdLine, int nCmdShow){ _CrtSetBreakAlloc(180); HRESULT hRes = ::CoInitializeEx(NULL, COINIT_MULTITHREADED); ATLASSERT(SUCCEEDED(hRes)); ::DefWindowProc(NULL, 0, 0, 0L); AtlInitCommonControls(ICC_BAR_CLASSES); //HINSTANCE hInstRich = ::LoadLibrary(CRichEditCtrl::GetLibraryName()); hRes = _Module.Init(NULL, hInstance); ATLASSERT(SUCCEEDED(hRes)); int nRet = Run(lpstrCmdLine, nCmdShow); _Module.Term(); ::CoUninitialize(); _CrtDumpMemoryLeaks(); return nRet; } 

Answer 1

Two sentences.

First, what is created before main (or the equivalent) begins to be destroyed after main completed. Calling _CrtDumpMemoryLeaks at the end of main may give you false positives. (Or are they false negatives?) Global object destructors are not running yet, and atexit callbacks are not running yet, so the leak output will include distributions that have not yet been properly released.

(I suspect that is why your global objects seem to be leaking. There is nothing wrong with the code, and it is indeed possible that it will clear correctly - the cleanup code still starts when _CrtDumpMemoryLeaks is called.)

Instead, you need to direct the runtime library to call _CrtDumpMemoryLeaks for you, after all, after all atexit callbacks and global object destructors have completed. Then you will see only real leaks. This snippet will do the trick. Insert at the beginning of main :

 _CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG)|_CRTDBG_LEAK_CHECK_DF); 

Secondly, if the above reveals true leaks from material that runs before main , you can cheat a little to make your own code a bit before anything else peeks inside. Then you can set _crtBreakAlloc before any distribution happens. Just enter the following code into your own .cpp file:

 #include <crtdbg.h> #ifdef _DEBUG #pragma warning(disable:4074)//initializers put in compiler reserved initialization area #pragma init_seg(compiler)//global objects in this file get constructed very early on struct CrtBreakAllocSetter { CrtBreakAllocSetter() { _crtBreakAlloc=<allocation number of interest>; } }; CrtBreakAllocSetter g_crtBreakAllocSetter; #endif//_DEBUG 

(I suspect that the code in the compiler initialization segment can be run before stdin and stdout , etc., is initialized and, of course, before any global objects are created, so it may be difficult for you to do something more complex, the higher!)

(Which costs little, I believe that these days, and for some time now this distribution before the start of main almost always bad. It makes it difficult to clean up after myself, and it’s difficult to track what is happening. It’s certainly convenient, but you always seem to end up paying for it later. This advice, which is a lot easier to hand out than to implement, however, especially as part of a larger team.)

Answer 2

I had several global variables (lookup tables that returned CString links to error messages) that I removed from the program. As soon as I did this, there were no memory leaks.

Thanks for your comments.

Interesting - I will have to explore another way to implement error searching.

I was doing something like:

 CString sError = "error at line x: " + g_map.lookup(hrError); 

The error map is implemented as an object that wraps access to std :: map, and the destructor works fine. When I allocate this map object in a heap and free it, it does not report a memory leak. Perhaps this is how I concatenate CString ....