Memory Leak in Constructor?

I know memory leak checking can sometimes have false positives. I'm wondering if this is one of them, or if I'm doing something wrong.

I turned on memory leak checking by adding

Code:

---

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

---

Then calling

Code:

---

_CrtDumpMemoryLeaks();

---

in the App's constructor.

I traced the issue back to the contructor for a variable included in the app class. The variable is a class I declare in the project.

Code:

---

//Class declaration

#define NUM_MT_COLORS 16
struct clrTable
{
    COLORREF clrCode;
    CString clrName;
};

class CColorTable
{
public:
    CColorTable();
    ~CColorTable();
    clrTable m_ClrTable[NUM_MT_COLORS+1];
};

---

Code:

---

//The contructor
CColorTable::CColorTable()
{
    m_ClrTable[0].clrCode = TT_BLACK;
    m_ClrTable[0].clrName=_T("Black");
    m_ClrTable[1].clrCode = TT_MAROON;
    m_ClrTable[1].clrName=_T("Maroon");
    m_ClrTable[2].clrCode = TT_DKGREEN;
    m_ClrTable[2].clrName=_T("Dk Green");
    m_ClrTable[3].clrCode = TT_BROWN;
    m_ClrTable[3].clrName=_T("Brown");
    m_ClrTable[4].clrCode = TT_DKBLUE;
    m_ClrTable[4].clrName=_T("Dk Blue");
    m_ClrTable[5].clrCode = TT_PURPLE;
    m_ClrTable[5].clrName=_T("Purple");
    m_ClrTable[6].clrCode = TT_AQUA;
    m_ClrTable[6].clrName=_T("Aqua");
    m_ClrTable[7].clrCode = TT_DKGREY;
    m_ClrTable[7].clrName=_T("Dk Gray");
    m_ClrTable[8].clrCode = TT_GREY;
    m_ClrTable[8].clrName=_T("Gray");
    m_ClrTable[9].clrCode = TT_RED;
    m_ClrTable[9].clrName=_T("Red");
    m_ClrTable[10].clrCode = TT_GREEN;
    m_ClrTable[10].clrName=_T("Green");
    m_ClrTable[11].clrCode = TT_YELLOW;
    m_ClrTable[11].clrName=_T("Yellow");
    m_ClrTable[12].clrCode = TT_BLUE;
    m_ClrTable[12].clrName=_T("Blue");
    m_ClrTable[13].clrCode = TT_VIOLET;
    m_ClrTable[13].clrName=_T("Violet");
    m_ClrTable[14].clrCode = TT_LTBLUE;
    m_ClrTable[14].clrName=_T("Lt Blue");
    m_ClrTable[15].clrCode = TT_WHITE;
    m_ClrTable[15].clrName=_T("White");
    m_ClrTable[16].clrCode = -1;  //Initially undefined
    m_ClrTable[16].clrName=_T("Custom");
}

---

I get a memory leak error for every instance where a CString is set. I tried moving this to the MainFrame just to see if there was something with this being in the app, and saw the same memory leak errors.

I didn't include the functions in this class that manipulate this table. I didn't put it in the document because this is a multi-doc application and this table is universal to the program.

Is this an example of a false positive in the memory leak checker, or did I do something wrong? If it's me, could someone enlighten me about what to do?

Thanks,
Bill

The only false positives I've ever seen from the CRT leak-checking happen when you allocate and delete memory in a static singleton. Apparently, the CRT initiates the leak-checking when a static singleton of it's own is destructed, or at least it acts that way. The problem is that the order of destruction of singletons in your program is not controlled, so if the leak-check is initiated before the destructor of your own singleton is called, you'll get a false positive.

From the bit you've posted, I suspect that's what you've got here. You said your color table variable is a member of your app class, but in MFC the app class is a singleton. (You might find it by looking for a comment added by the App Wizard which says "The one and only [your app class name] object", though I don't know if the comment still gets added by more recent versions of VS.)

I can't remember if the Main Frame object is also a singleton, but one way to confirm whether this is the problem would be to put a breakpoint in your CColorTable destructor, or in the destructor for the app class if your color table is still a member variable there. Run your program, then exit out. When your breakpoint gets hit, check your debug output window to see if the memory leak complaint has already been outputed.

I put a breakpoint at the beginning of the constructor for the app class. Then I put _CrtDumpMemoryLeaks(); on the first line of the constructor. Stepping past the call to the dump memory leaks displays the leak messages. It doesn't look like much of anything else is being called between the break point and the call to the dump memory leaks except the constructor for this class. I tested it by creating a test program and just putting the CColorTable in it.

I think my breakpoint is at the first possible spot where you could put a breakpoint in an MFC program.

Bill

_CrtDumpMemoryLeaks prints every C++ allocation which is not released yet. The name is misleading: its impossible to say, whether unrelaesed memory is leak or not:

Code:

---

char*p = new char[100];
_CrtDumpMemoryLeaks();    // p is reported
delete[] p;

---

You don't need to call _CrtDumpMemoryLeaks explicitly, it should be called by framework, when all user allocated memory must be released. In this case, every memory block, reported by _CrtDumpMemoryLeaks, is really leak. In MFC application _CrtDumpMemoryLeaks is called automatically. In non-MFC application add this code to the beginning of the program:

Code:

---

_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);

---

This is enough to enable memory leaks detection.

Quote:

---

Originally Posted by wdolson

I'm wondering if this is one of them, or if I'm doing something wrong.

---

There's nothing in the code that can cause a leak. Either you're using the leak detection mechanism wrongly or the leak is elsewhere.

Are you using new on CColorTable somewhere. Maybe you're doing it twice by mistake without a delete in-between.

I misunderstood how it works. The program does have some problems. I started down the memory leak possibility when I started getting corruption in the heap errors on program exit.

The program was using an OCX built on a sample on CodeProject. We had some problems with installing it on some systems in corporate environments, so I modified it into a CWnd based control. It mostly works, but throws some heap errors when outputting to a file or printing.

When I just start the program and immediately quit without doing anything I do get one memory leak. I just discovered that, so I need to run that down before I can say anything else about it.

Bill

Quote:

---

Originally Posted by wdolson

When I just start the program and immediately quit without doing anything I do get one memory leak.

---

So isn't the location of "detected memory leak" shown?
Check it out: How to Find the Source of Memory Leaks

Quote:

---

Originally Posted by wdolson

I misunderstood how it works. The program does have some problems. I started down the memory leak possibility when I started getting corruption in the heap errors on program exit.

---

Memory leaks don't cause heap corruption. At worst, they can make your program run out of memory. That's not to say you shouldn't fix them, of course.