none
No File Information Being Generated for _CrtDumpMemoryLeaks

    Question

  • Hey all,

    I'm trying to use the VC++ Memory Leak detection utilites and while it seems to be working for the most part, I can't seem to get it to generate the File and Line information for me. 

    As per the information on this page: http://msdn2.microsoft.com/en-us/library/e5ewb1h3(VS.80).aspx
    I have included the given libraries and defined the _CRTDBG_MAP_ALLOC constant, but I'm still not getting the file and line information when I call _CrtDumpMemoryLeaks. 

    In the process of writing this message I realized that it might be due to the fact that most of my code is using new.  Is it possible to get file/line info using new? 

    On the otherhand, I have a C library that I wouldn't mind watching for allocations, so if I want to allow it to map the allocations from that library I'm assuming that I need to recompile  it with the above includes, correct?
    Saturday, March 01, 2008 1:05 AM

Answers

  • With a little bit of extra code, you can get it to work with new/delete:


    Code Snippet

    // 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 = new char[10];
        char *b = (char*)malloc(20);
        _CrtDumpMemoryLeaks();
        return 0;
    }




    ---
    @MS: And fix the bloody code block button with Opera already! And the rest of the site! (Had to post with firefox)
    Saturday, March 01, 2008 6:45 AM
  •  

    Your assessment is correct - that macro applies only to C library

    functions, not to C++. You can see which functions are affected

    by looking in crtdbg.h for the #ifdef  _CRTDBG_MAP_ALLOC
    block. I'm not aware of a similar facility for C++ in VC++, only

    in other debuggers.

     

    Yes, you will have to recompile the library. The activation is

    accomplished via macros which get applied to your source code

    by the preprocessor prior to compilation.

     

    - Wayne

     

    Saturday, March 01, 2008 4:34 AM

All replies

  •  

    Your assessment is correct - that macro applies only to C library

    functions, not to C++. You can see which functions are affected

    by looking in crtdbg.h for the #ifdef  _CRTDBG_MAP_ALLOC
    block. I'm not aware of a similar facility for C++ in VC++, only

    in other debuggers.

     

    Yes, you will have to recompile the library. The activation is

    accomplished via macros which get applied to your source code

    by the preprocessor prior to compilation.

     

    - Wayne

     

    Saturday, March 01, 2008 4:34 AM
  • With a little bit of extra code, you can get it to work with new/delete:


    Code Snippet

    // 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 = new char[10];
        char *b = (char*)malloc(20);
        _CrtDumpMemoryLeaks();
        return 0;
    }




    ---
    @MS: And fix the bloody code block button with Opera already! And the rest of the site! (Had to post with firefox)
    Saturday, March 01, 2008 6:45 AM
  • Great replies guys.  Thanks for the code snippit scorpion, it's working perfectly.

    - Ben
    Saturday, March 01, 2008 9:24 AM

  • I just tried adding the lines suggested to display the allocations via new, but I get a whole bunch of errors, starting with:
    1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(32) : warning C4229: anachronism used : modifiers on data are ignored
    1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(32) : error C2365: 'operator new' : redefinition; previous definition was 'function'
    1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(32) : error C2491: 'new' : definition of dllimport data not allowed
    1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(32) : error C2078: too many initializers
    1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xdebug(32) : error C2440: 'initializing' : cannot convert from 'int' to 'void *'
    1>        Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast

    I'm using Visual Studio 2008 Express - is this feature disable for Express, or did I miss something.

    BTW, without the new redefinitions, the block allocated by malloc does show the file and linenumber as expected.

    TIA
    Wednesday, May 07, 2008 5:41 PM
  •  

    Since the errors you show are from one of the compiler's header files,

    I suspect that you inserted the defines *before* the include statements.

    They should only be added *after* all header includes.

     

    - Wayne

     

     

    Wednesday, May 07, 2008 8:38 PM

  • Thank you for the quick reply.
    The #defines were after the includes, but not after _all_ of my headers, so you were quite right, but ... ;-)

    When I move the works to below _all_ of my headers, the allocations made via malloc - which showed when I did not add the define stuff - no longer show the file information.

    Seems I can have one or the other, but not both in one run.

    Also since my current app uses a main program and several dll, I'll have to see in which one the leaks are, since including the defines and headers in the main app did not - of course - identify any leaks in the dlls.

    Just the same it is very encouraging to see there is some way to get at this, other than plain old trial and error.
    Wednesday, May 07, 2008 9:47 PM
  •  

    Quote>Seems I can have one or the other, but not both in one run.

     

    No, that's wrong. My suggestion that you move the defines to after the

    headers was in reference to the lines you added to get line/file info for

    allocations via new. Those were the lines you added which caused

    errors. Now it sounds like you did more than I suggested and also

    moved the #define _CRTDBG_MAP_ALLOC line to after the headers

    as well. If so, you should not have done that. It needs to be before the

    headers.

     

    - Wayne

     

    Thursday, May 08, 2008 12:29 AM


  • Thank you again - that finally did the trick :-)

    What I have now is:
    ==================
    #define _CRTDBG_MAP_ALLOC

    #include "wxWdh.h"
    #include "wxWdFrameh.h"

    #include <stdlib.h>
    #include <crtdbg.h>
    #ifdef _DEBUG
    #define DEBUG_NEW new(_NORMAL_BLOCK, __FILE__, __LINE__)
    #define new DEBUG_NEW
    #endif
    ===================
    And I can see leaked block from both malloc and new.

    PS: I hope this won't become a duplicate reply - something seemed to go wrong the last time I tried to submit my reply.
    Thursday, May 08, 2008 3:30 AM
  • Well this does not work (actually causes error messages) whenever class member allocation functions (new/delete as class functions) or placement allocators are used.

    While the latter are unimportant (they do not allocate memory), the first are not too uncommon, and these macros you describe cause compilation errors.

    Christian

    Thursday, May 08, 2008 1:04 PM

  • All I can say is that it did work for me thus far; I have been able to identify the cause of 3 out of 5 of the leaks in my case - although I haven't figured out how to remove the leaks since it seems to be happening inside some 'magic' macros.
    I still have two more to go - and I'm sure there will be a few more to find as time goes on and testing progresses, so there may be leaks that this won't find, but for now,I'm quite pleased to find at least some of them.
    Thursday, May 08, 2008 4:12 PM
  • It's enough to put
    #ifdef _DEBUG
    #define new DEBUG_NEW
    #endif

    DEBUG_NEW is already declared in afx.h
    Thursday, March 19, 2009 11:07 AM
  • Quote>DEBUG_NEW is already declared in afx.h

    That header is not included with the Express Editions,
    as it is part of MFC.

    - Wayne


     

    Thursday, March 19, 2009 8:53 PM
  • Since I am working on DLL's, I don't have main(). My DLL's are called by another application. I only have various functions in my DLL. And if I put _CrtDumpMemoryLeaks(); inside a function just before the return, it compiles fine but it does not print anything in the output pane of the debug window. ( I am attaching the process that uses my DLL  before I start debug). Any clue what could be done ? Thank you.
    • Proposed as answer by girish kamat Sunday, October 11, 2009 3:18 PM
    Thursday, October 01, 2009 7:50 PM
  • Your Dll will have DllMain function like extern "C"
    BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID /*lpReserved*/);
    Include following statement therein
    if (dwReason == DLL_PROCESS_DETACH)
     {

      _CrtDumpMemoryLeaks(); 
     }
       

    Sunday, October 11, 2009 3:21 PM
  • Perfect; miniTester's code (minus the #include "wx*.h" lines) works for me.

     

    Thanks

    Thursday, July 29, 2010 9:01 AM
  • In the case of a class that overloads the new or delete operator, you have to undefine new (your not turning delete into a macro, so no need to worry about that) around the definition of your class and it's implementation (assuming the implementation is in another file).

    This is done by using #pragma push_macro and #pragma pop_macro. This temporarily disables the new macro in a block of code, and then reverts back to the definition afterwards.

     

    // header file
    
    #pragma push_macro("new")
    #undef new
    class MeToo
    {
    ...
    operator new(...);
    };
    #pragma pop_macro("new")
    
    // cpp file
    
    #pragma push_macro("new")
    #undef new
    MeToo::operator new(...)
    {
    	// stuff 
    }
    #pragma pop_macro("new")
    

     

    Wednesday, January 12, 2011 11:17 AM