One frustrating experience with MSFT documentation is realizing that in reality things just don't work as smoothly as one is made to believe. For example, tracking source lines through simply adding "#define _CRTDBG_MAP_ALLOC" is something that almost NEVER has worked for me, even though I have been trying this in my projects so many times. And then, each time I am left on my own to guess what could be wrong, since nobody responsible for this documentation seems to have tested this procedure under more complicated circumstances than what appears to be the most basic kind of application, which is probably some console .exe application. Also, a known bug that causes incorrect source lines to be reported (if at all), and which is also described in "Debugging Applications for Microsoft .NET and Microsoft Windows" by John Robbins is nowhere described in the official documentation. Is this one of the issues that MSFT so often refers to as "not a known issue"? I can hardly believe that those things have not already come to the attention of MFST.....

One frustrating experience with MSFT documentation is realizing that in reality things just don't work as smoothly as one is made to believe. For example, tracking source lines through simply adding "#define _CRTDBG_MAP_ALLOC" is something that almost NEVER has worked for me, even though I have been trying this in my projects so many times. And then, each time I am left on my own to guess what could be wrong, since nobody responsible for this documentation seems to have tested this procedure under more complicated circumstances than what appears to be the most basic kind of application, which is probably some console .exe application. Also, a known bug that causes incorrect source lines to be reported (if at all), and which is also described in "Debugging Applications for Microsoft .NET and Microsoft Windows" by John Robbins is nowhere described in the official documentation. Is this one of the issues that MSFT so often refers to as "not a known issue"? I can hardly believe that those things have not already come to the attention of MFST.....

CAUTION!

When using the method of including the call

_CrtDumpMemoryLeaks();

just before your program exits, remember that the destructors for any variables you declared at runtime (i.e. any variables declared not using the 'new' operator) have *NOT* been called yet. This makes the memory holding these variables look like leaked memory when in fact the memory will be cleaned up just prior to program exit.

For this reason, I highly recommend that you use the other method described, i.e. the first line of your main() function reads

_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

This allows you to not have to worry about covering all your program exits with a call to _CrtDumpMemoryLeaks() and also allows for calls to destructors before testing for memory leaks.

I think it was somewhat irresponsible to leave this information out of this article - it seems pretty fundamental to the concept of leak detection. If anything, the _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ) should have been listed first...


Good luck!

When using free/malloc/realloc it's ok,

but how find leak for new and delete in the same way ?

I find this : (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2931462&SiteID=1)

// compile with cl /D_DEBUG /MDd /EHsc leak2.cpp

#define

_CRTDBG_MAP_ALLOC

#include

<iostream>

#include

<crtdbg.h>

#ifdef

_DEBUG

#define

DEBUG_NEW new(_NORMAL_BLOCK, __FILE__, __LINE__)

#define

new DEBUG_NEW

#endif

int

main()

{

char *a = newchar[10];

char *b = (char*)malloc(20);

_CrtDumpMemoryLeaks();

return 0;

}

this will not show file name and line number in the output, vs2005, no idea what is wrong

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

#define NUM_PTRS 5
#define MEM_SIZE 150
void* g_ptrs[NUM_PTRS];
UINT thread_malloc(LPVOID param)
{
for(int i = 0; i < NUM_PTRS; i++)
{
g_ptrs[i] = malloc(MEM_SIZE);
memset(g_ptrs[i], 0, MEM_SIZE);
}
return 0;
}
void Cmalloc_thread_testDlg::OnBnClickedButton1()
{
AfxBeginThread(thread_malloc, NULL);
}

void Cmalloc_thread_testDlg::OnBnClickedButton3()
{
_CrtDumpMemoryLeaks();
}