[RESOLVED] I'm not sure if I this should be considered as a memory leak

I have this MFC program that was migrated from VS 2002 to VS 2003 and now to VS 2008. It is a dialog based program with quite a few controls on its main window. I don't use owner-drawn controls, but some of those controls might have been subclassed.

I just discovered that if I monitor this program's memory usage with a Task Manager on Windows 7 while dragging it all over the screen (to force re-painting), the follow happens:

Handle count == stays the same
User Objects count == stays the same
GDI Objects count == stays the same

but

Memory - Private Working Set == slowly grows up about 20K a second (only when I drag the program's window)
Memory - Working Set = Also grows at the same rate.

I looked all over a possible OnPaint() or OnDrawItem() leak but found absolutely nothing wrong with the code. I tried to comment out chunks of code that may be called for repainting to no effect either.

I also observed that this memory leak doesn't slow down if I keep on dragging my window and continues on for as long as I force repaiting.

Shall I be concerned about it? And if there're any products that are compatible with Visual Studio 2008 that can detect this kind of a resource/memory leak? FYI, I tried built-in leak detector and it didn't show anything.

Some change in private working set and working set is to be expected. It simply means that Windows is keeping more of this program in actual RAM to keep the program responsive rather than continuously page stuff back out.

If the 'Commit Size' of your application is growing and keeps growing as long as you move the window, then you probably do have some sort of memory leak. Although at the same count, this could be normal behaviour of the program.

Another question is: does the memory usage comes down after you stop dragging your window?

Quote:

---

Originally Posted by OReubens

If the 'Commit Size' of your application is growing and keeps growing as long as you move the window, then you probably do have some sort of memory leak. Although at the same count, this could be normal behaviour of the program.

---

Good point, I didn't think about it. But, unfortunately Commit Size also goes up, not as fast as Working set though.

And to answer Vladimir's question, no, it doesn't come down when I stop moving the window. It only stops but when I start dragging it again, it continues to grow.


PS. I hate these things when they happen.

OK. I think I got to some closure... first off, I don't know if I said that this is a converted MFC dialog based project. So, using the exclusion method I narrowed it down to this. If I comment out the ON_WM_ERASEBKGND line from the BEGIN_MESSAGE_MAP for my CDialog derived class the memory leak disappears. Mind you, if I comment out the OnEraseBkgnd handler to the bare bones line this:

Code:

---

BOOL OnEraseBkgnd(CDC* pDC)
{
        // TODO: Add your message handler code here and/or call default

        return CDialog::OnEraseBkgnd(pDC);
}

---

It still leaks like a sieve. Did anyone encounter this kinda thing with MFC?

PS. If I create a new dialog based project with VS 2008 w/o SP1 and try the same handler, it doesn't produce this leak.

OK. I got to the bottom of it. The reason clearly was CDialog::OnEraseBkgnd() handler that was leaking memory in DC management. (Don't know exactly where, and I don't think that I care at this point.) There are couple of references to this issue on the web: one, and here's another.

I might actually endorse this statement, but unfortunately I'm too deep in it:

Quote:

---

Remind me again why I avoid MFC like the plague? Oh yeah, now I remember!
It has weird leaks and bugs that have been there forever, it adds a lot of
overhead that's unnecessary, it allows people to write apps without
understanding basic Win32 programming or fundamentals, and it's a pain in
the *** to debug.

---

BTW, I do not subscribe to the fix posted there.

The workaround in my case was to override WindowProc like so:

Code:

---

LRESULT WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
{
        // TODO: Add your specialized code here and/or call the base class

        if(message == WM_ERASEBKGND)
        {
                //Do default background processing first
                DefWindowProc(message, wParam, lParam);

                //Call my erase background override
                OnEraseBkgnd_Override((HDC)wParam);
                return 1;
        }

        return CDialog::WindowProc(message, wParam, lParam);
}

---

So everyone who uses older, or migrated their old MFC dialog-based projects to VS 2008 with CDialog::OnEraseBkgnd() handler override, check for memory leaks.