Click here to Skip to main content
Click here to Skip to main content

Catching memory leaks

, 4 Oct 2000
Rate this:
Please Sign up or sign in to vote.
How catch memory leaks with very little effort
<!-- Link to demo file download -->
  • Download demo project - 7 Kb
  • <!-- Add the rest of your HTML here -->


    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 a simple case you should add several lines to 'StdAfx.h'

    #ifdef _DEBUG
       #define _CRTDBG_MAP_ALLOC // include Microsoft memory leak detection procedures
       #define _INC_MALLOC	     // exclude standard memory alloc procedures

    Note: it should be before the 'include' directives.

    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.

    Detected memory leaks!
    Dumping objects -> D:\Projects\CrtDbg\CrtDbg.cpp(25) : {53} normal block at 0x002F26C0, 10 bytes long.
    Data: <MemoryLeak> <MEMORYLEAK> 4D 65 6D 6F 72 79 4C 65 61 6B 
    Object dump complete.

    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.


    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


    About the Author

    Audrius Vasiliauskas
    Business Analyst
    Lithuania Lithuania
    No Biography provided

    Comments and Discussions

    GeneralUnhandled exception in ntdll Pinmembered welch16-Apr-09 13:59 
    GeneralRe: Unhandled exception in ntdll PinmemberAudrius Vasiliauskas18-Apr-09 7:53 
    Generalerror C2065: 'alloca' : undeclared identifier Pinmembersafety_ruk25-May-06 23:13 
    GeneralRe: error C2065: 'alloca' : undeclared identifier Pinmemberakulkarni19-Jul-06 12:42 
    GeneralRe: error C2065: 'alloca' : undeclared identifier Pinmemberakulkarni19-Jul-06 12:42 
    Questionafxpriv.h Pinmemberehh8-Sep-05 9:49 
    QuestionHow to find real leaked point Pinmembermurakami15-Aug-05 23:44 
    AnswerRe: How to find real leaked point PinmemberTim Read29-May-06 7:23 
    AnswerRe: How to find real leaked point Pinmembermurakami29-May-06 18:01 
    GeneralRe: How to find real leaked point PinmemberTim Read31-May-06 0:20 
    GeneralDebugging a DLL - no StdAfx.h available Pinmemberbschorre30-Mar-05 3:00 
    GeneralAn extremely useful tip PinsussAnonymous11-Apr-04 20:52 
    GeneralRe: An extremely useful tip Pinmemberworksopbenny7-Jun-04 23:54 
    GeneralSoooooooo Coooooool Pinmemberinternal10-Jun-04 17:28 
    GeneralRe: An extremely useful tip Pinmemberpeterboulton9-Dec-04 2:24 
    This is indeed a good tip.

    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:

    long allocReqNum;
    char *my_pointer;
    my_pointer = (char*)malloc(10);
    _CrtIsMemoryBlock(my_pointer, 10, &allocReqNum, NULL, NULL);
    free(my_pointer); // Breakpoint on first run and note value of allocReqNum

    _CrtSetBreakAlloc(allocReqNum+1); // Comment out on first debug run


    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.

    GeneralRe: An extremely useful tip PinmemberRainKing Fool4-Oct-05 16:43 
    Generalabout VC7 PinmemberMuhammad Ahmed5-Feb-04 1:14 
    GeneralNot Getting the path where actully memory leak occuring PinmemberJaymin5-Aug-03 3:26 
    GeneralMemory Leak PinsussSivakumar R28-Mar-03 0:59 
    Generalabout call stack PinmemberNing Cao7-Jan-03 16:55 
    GeneralRe: about call stack PinmemberMike Nordell7-Jan-03 17:25 
    GeneralRe: about call stack PinmemberNing Cao7-Jan-03 17:35 
    GeneralRe: about call stack PinmemberKita24-Jun-03 22:33 
    Generalabout custom memory management PinmemberNing Cao7-Jan-03 16:50 
    GeneralMemory leak detection PinmemberYud27-Feb-01 22:48 
    GeneralI also meet this problem, can anyone give me some idea? Pinmemberbenben8-Dec-03 16:38 
    QuestionATL support? PinmemberMichael Groeger17-Jan-01 23:50 
    AnswerRe: ATL support? PinmemberAudrius Vasiliauskas18-Jan-01 0:22 
    GeneralRe: ATL support? PinmemberMichael Groeger6-Feb-01 3:42 
    GeneralRe: ATL support? PinsussStuart Tett18-May-05 8:19 
    GeneralRe: ATL support? PinmemberYud27-Feb-01 22:43 
    GeneralDoesn't work all the time PinsussDaníel B. Sigurgeirsson10-Oct-00 7:49 
    GeneralPRB: _CRTDBG_MAP_ALLOC Does Not Work as Documented PinsussMartin Ziacek15-Sep-00 9:30 
    GeneralRe: PRB: _CRTDBG_MAP_ALLOC Does Not Work as Documented PinsussAnonymous2-Nov-00 23:05 
    GeneralRe: PRB: _CRTDBG_MAP_ALLOC Does Not Work as Documented PinsussAnonymous2-Nov-00 23:05 
    GeneralRe: PRB: _CRTDBG_MAP_ALLOC Does Not Work as Documented PinsussAnonymous2-Nov-00 23:06 
    QuestionHow about DEBUG_NEW PinsussJRB12-Sep-00 6:11 
    AnswerRe: How about DEBUG_NEW PinsussAudrius Vasiliauskas13-Sep-00 23:34 
    QuestionHow about DEBUG_NEW PinsussJRB12-Sep-00 6:10 

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

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

    | Advertise | Privacy | Terms of Use | Mobile
    Web04 | 2.8.150414.1 | Last Updated 5 Oct 2000
    Article Copyright 2000 by Audrius Vasiliauskas
    Everything else Copyright © CodeProject, 1999-2015
    Layout: fixed | fluid