CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 6 of 6
  1. #1
    Join Date
    Feb 2009
    Location
    Portland, OR
    Posts
    1,488

    [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.

  2. #2
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: I'm not sure if I this should be considered as a memory leak

    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.

  3. #3
    Join Date
    Aug 2000
    Location
    New York, NY, USA
    Posts
    5,656

    Re: I'm not sure if I this should be considered as a memory leak

    Another question is: does the memory usage comes down after you stop dragging your window?
    Vlad - MS MVP [2007 - 2012] - www.FeinSoftware.com
    Convenience and productivity tools for Microsoft Visual Studio:
    FeinWindows - replacement windows manager for Visual Studio, and more...

  4. #4
    Join Date
    Feb 2009
    Location
    Portland, OR
    Posts
    1,488

    Re: I'm not sure if I this should be considered as a memory leak

    Quote Originally Posted by OReubens View Post
    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.

  5. #5
    Join Date
    Feb 2009
    Location
    Portland, OR
    Posts
    1,488

    Re: I'm not sure if I this should be considered as a memory leak

    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.

  6. #6
    Join Date
    Feb 2009
    Location
    Portland, OR
    Posts
    1,488

    Re: I'm not sure if I this should be considered as a memory 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:
    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.
    Last edited by ahmd; July 22nd, 2010 at 11:17 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured