Click here to Skip to main content
15,867,568 members
Articles / Desktop Programming / MFC
Article

Detailed memory leak dumps from a console app

Rate me:
Please Sign up or sign in to vote.
4.79/5 (16 votes)
21 May 20021 min read 203.1K   57   45
How to get path and line number info for memory leaks, in a console app

Introduction

Finding memory leaks in a non-MFC app can be difficult because the debugger doesn't display path and line number info in the debug window. But, it's quite easy to enable that info. Here's how:

Step 1

Copy this to a file called LeakWatcher.h

#ifndef IMWATCHINGYOULEAK
#define IMWATCHINGYOULEAK

#include <crtdbg.h>

#ifdef _DEBUG
void* operator new(size_t nSize, const char * lpszFileName, int nLine)
{
    return ::operator new(nSize, 1, lpszFileName, nLine);
}
#define DEBUG_NEW new(THIS_FILE, __LINE__)

#define MALLOC_DBG(x) _malloc_dbg(x, 1, THIS_FILE, __LINE__);
#define malloc(x) MALLOC_DBG(x)

#endif // _DEBUG

#endif // #include guard

Step 2

Call _CrtDumpMemoryLeaks(); at the end of your program (or wherever you want to see outstanding memory allocations).

Steps 3...N

Add this to each of your source files (after your last #include) :

#include "LeakWatcher.h"

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

What does it do?

This does the same thing an MFC app does - it provides the path and line number of each allocation to the C-runtime allocation routines. Those routines store the path and line number for each allocation, and spit them out when you call _CrtDumpMemoryLeaks();. You should recognize that little chunk of code in step 3 from every source file that the AppWizard (and ClassWizard, mostly) has ever created.

Why not just use _CRTDBG_MAP_ALLOC?

#define _CRTDBG_MAP_ALLOC will provide file/line info for leaks caused by malloc, but for leaks with new, it ends up telling you that the leak occurred in crtdbg.h (because that's where MS defined their new) - not really useful.

Credits

This represents about ten minutes of searching through Microsoft's C runtime and MFC source files. So, all of the credit goes to MS. But, all of the blame goes to MS, too, for not making this part of the non-MFC headers. Anyway, have fun and be excellent to each other.

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.

A list of licenses authors might use can be found here


Written By
Software Developer
United States United States
Chris Losinger was the president of Smaller Animals Software, Inc. (which no longer exists).

Comments and Discussions

 
AnswerBetter way to avoid unfiled and unlided memory leaks is to Pin
steveb16-Aug-12 14:04
mvesteveb16-Aug-12 14:04 
GeneralHit or Miss on the line number reporting... Pin
heckknow24-Dec-06 11:54
heckknow24-Dec-06 11:54 
GeneralRe: Hit or Miss on the line number reporting... Pin
gameengineer15-Mar-07 10:16
gameengineer15-Mar-07 10:16 
GeneralTwo Problems Pin
Andrew Nosworthy4-May-05 21:36
Andrew Nosworthy4-May-05 21:36 
GeneralRe: Two Problems Pin
Andrew Nosworthy4-May-05 21:37
Andrew Nosworthy4-May-05 21:37 
GeneralRe: Two Problems Pin
Chris Losinger5-May-05 0:59
professionalChris Losinger5-May-05 0:59 
GeneralRe: Two Problems Pin
Andrew Nosworthy5-May-05 13:34
Andrew Nosworthy5-May-05 13:34 
GeneralRe: Two Problems Pin
Nosferatus22-Jul-05 5:53
Nosferatus22-Jul-05 5:53 
GeneralRe: Two Problems Pin
Bob Stanneveld1-Feb-06 21:15
Bob Stanneveld1-Feb-06 21:15 
QuestionWhere is memory leak from? Pin
morntide25-Feb-05 16:05
morntide25-Feb-05 16:05 
AnswerRe: Where is memory leak from? Pin
Nosferatus22-Jul-05 5:59
Nosferatus22-Jul-05 5:59 
Questionisn't this better? Pin
Anonymous2-Feb-05 0:17
Anonymous2-Feb-05 0:17 
GeneralWhere to put _CrtDumpMemoryLeaks() for Dialog based applications... Pin
rbid21-Dec-04 21:16
rbid21-Dec-04 21:16 
GeneralTHIS_FILE redefinition Problems Pin
Anonymous5-Jan-04 16:37
Anonymous5-Jan-04 16:37 
GeneralRe: THIS_FILE redefinition Problems Pin
Anonymous5-Jan-04 17:23
Anonymous5-Jan-04 17:23 
GeneralRe: THIS_FILE redefinition Problems Pin
Chris Losinger6-Jan-04 1:32
professionalChris Losinger6-Jan-04 1:32 
GeneralRe: THIS_FILE redefinition Problems Pin
Anonymous6-Jan-04 14:14
Anonymous6-Jan-04 14:14 
GeneralRe: THIS_FILE redefinition Problems Pin
Anonymous6-Jan-04 14:40
Anonymous6-Jan-04 14:40 
GeneralRe: THIS_FILE redefinition Problems Pin
Chris Losinger6-Jan-04 14:53
professionalChris Losinger6-Jan-04 14:53 
GeneralRe: THIS_FILE redefinition Problems Pin
Anonymous7-Jan-04 3:11
Anonymous7-Jan-04 3:11 
GeneralRe: THIS_FILE redefinition Problems Pin
Chris Losinger7-Jan-04 3:39
professionalChris Losinger7-Jan-04 3:39 
GeneralRe: THIS_FILE redefinition Problems Pin
Anonymous7-Jan-04 4:34
Anonymous7-Jan-04 4:34 
Aha! All problems solved!

At first I wasn't using an ultra simple project to test it on, merly a simple one. Note in my first post I said:
"...I tried substituting #define THIS_FILE __FILE__. ..."

In the post immediatly after that, dated 23:23 5 Jan '04 as far as I can see, I list a whole host of errors that I got when I tried it. They didn't make a whole lot of sense to me (and I've using VC++ for a long while now), so I assumed it was some macro complication.

I've found out now that they cropped up not because they were caused by the #define THIS_FILE __FILE__, but rather they were just 'revealed' because the #define fix succeeded, and allowed compilation to get to them...

I've been tinkering with an ultra simple project since, and because your suggested use of the #define fix worked in the ultra simple project and not in the simple project, I wanted to know why...

Long storey slightly shorter, those errors in the 'new' file cropped up because the order of the includes in main.cpp was:

#include "header1.h"<br />
#include <iostream><br />
#include <debug_crt.h>


I remember you advising in the article to place the debug_crt.h (in my case) after all previous #includes. Well that #include < iostream > (which wasn't in the ultra simple project) effectively isn't before it, because header1.h contains debug_crt.h and of course it is before debug_crt.h.

I'm not quite sure of the whys, or the exact causes for the errors, all I know is:

// All normal headers first<br />
#include < iostream ><br />
// All headers using debug_crt.h next<br />
#include "header1.h"<br />
// And finally debug_crt.h last<br />
#include < debug_crt.h >


Fixes 'em!
P.S. sometimes one needs to do a 'rebuild all', VC++ sometimes doesn't do a build normally. I'm getting 'operator DEBUG_NEW not recognized' errors, for example. I'm not sure if it's the .h files with declarations and definitions, or not...

Many thanks for the assist!
GeneralRe: THIS_FILE redefinition Problems Pin
Anonymous7-Jan-04 4:39
Anonymous7-Jan-04 4:39 
Generalspecialized &quot;new&quot; is never called Pin
blizzymadden25-Nov-03 12:46
blizzymadden25-Nov-03 12:46 
GeneralLink Errors Pin
Christian Cheney19-Nov-02 5:59
Christian Cheney19-Nov-02 5:59 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.