_CRTDBG_MAP_ALLOC useful information



  • Probably it's all my fault, but still - I think it's rather funny, that using:

    #define _CRTDBG_MAP_ALLOC

    which should have listed the lines of code where I have allocated memory, actually lists :

    (...)c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {15764} normal block at 0x0034FD38, 16 bytes long.
    Data: < > 01 00 00 00 01 00 00 00 00 00 00 00 04 00 00 00 
    c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {15761} normal block at 0x005B1850, 76 bytes long.
    Data: < M SUBST > C4 D1 4D 00 CD CD CD CD 53 55 42 53 54 00 CD CD 
    

    Object dump complete

    ... which obviously is the result of overloading the 'new' operator in crtdbg.h for the purpose of this listing.

    Yeah, I know - there must be some way to overcome this (I'm using VS 2003), but it's just silly it doesn't work as described in the MSDN.

    Of course the real WTF is that I'm having memory leaks and can't figure out what's going on without this tool :)



  • Found this on an MSDN forum, and it looks correct (ie, it appears to be the same content that the IDE would inject into files automatically - however, I don't see it anymore and mine seems to work... maybe just dumping all of it into stdafx.h would work or something):

     

      The setup described in that document is enough to see the source file/line for memory allocations made via malloc(). For allocations made via 'new' it is not enough, additionally you have to do something like the following:

    1. After #include <crtdbg.h>:

    #define DEBUG_NEW new(_NORMAL_BLOCK, THIS_FILE, __LINE__)

    2. At the beginning of every source file with memory allocations:

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

    A wizard-generated MFC application can be used as a sample.

    Also there is a simpler way - use a tool that can setup everything for you. For example, take a look at this one:

    http://www.codeproject.com/tools/leakfinder.asp



  • The real WTF here is the way that MSDN articles are written completely by tech writers, many without any experience writing code.

    The code on MSDN is all meant to be sample code. It wasn't (and I believe still isn't) ever compiled, so chances of it working are rather slim.



  • I've seen some quality samples of how never to write code.  It's helped when trying to explain why people shouldn't do certain things.



  • MSDN is full of examples that should never be used in practice.  The majority of the ASP.NET sample code is unbelievably bad!


Log in to reply