Question

I was using VS2008.

It’s a long time since I last time wrote memory leak code :), until I met this one.
it is reported from: \atlmfc\src\mfc\plex.cpp(29) :

the MFC “CPlex::Create” is invoked when the CMap::SetAt is called while “pAssoc = NewAssoc()” is invoked to assign memory.

I understand that, release a container by just calling “RemoveAll()” is not enough, need to iterate each entry and delete each of them.

But in this case, all I wanted is to used CMap to store the pair, I don’t want the CMap to delete the value pointer it stored. (The other container handles that.)

Note: this memory leak also happened in “CMapStringToPtr”(reported by other developer and googled them, not tested to confirm)

01    typedef CMap <int, int, CNode*, CNode*&> CNodeIndexMap;
02    CNodeIndexMap m_mapIndexToNode;
03    CNode* pNode = ... //This pNode is from another container, which is responsible for the nodes' clean
04    m_mapIndexToNode.SetAt(nIndex, pNode);
      ....
05    m_mapIndexToNode.RemoveAll();

      //Clean node list
06    for(int i = 0; i < lstNode.GetCount(); i++)
07    {
08        CNode* pNode = lstNode.GetAt(i);
09        delete pNode;
10    }
11    lstNode.RemoveAll();

I guess this is a microsoft bug. If that is really the case, what is the data structure I can use to create an “index table” and how to use it properly?

Any idea or comment on this memory leak?

Answer 1

In short, my code has a memory leak like: (I used CList as example)

CList<T>* pList = new CList<T>();
pList.AddTail(...);

If I forget to delete pList;, of course I will have a memory leak, reported as plex.cpp(29)

The point is: I didn’t add the macro:

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

If I add them to the .cpp files, these memory leaks will be reported with the correct file name and line number.

As I did not add this macro, the first .CPP file that has #define new DEBUG_NEW defined is responsible to report the memory leak.
That’s why plex.cpp occured in the debug messages.