We are working on an MFC based tool (I know, I know, MFC is outdated and ugly) and we were looking at Windows Task Manager and have been noticing a consistent memory leak with the tool. We have commented out all of our rendering and logic code, and we still are leaking about 4K a second, and about 8K every other second. We have narrowed it down to a SetDlgItemText() call, which when commented out takes away the 8K leak. We have been using CStrings, but even have attempted to use a const string literal like "HELLO" and we still get a leak. So, our assumptions are that either SetDlgItemText() has a known issue (which isn't documented either in MSDN or across the web according to Google) or Windows Task Manager is a liar, or we are a couple of idiots and are using SetDlgItemText() incorrectly. I brought out some old MFC apps to see if the same thing was happening and oddly enough it was. Anyone else run into this issue before? We could use some insight, thanks.

anybody have any ideas?

SetDlgItemText IS documented.

If you're having issues with it, it's probably somewhere else in your code, or else there would be massive out cry about it on the internet, as it's probably one of the most commonly called functions in win32 applications programming.

Maybe your sending it a string that isn't null terminated?

I wasn't trying to say SetDlgItemText wasn't documented, I was saying there was no documentation pertaining to any potential memory leaks concerning the use of the function.

The sending a non-null terminated string theory isn't correct because I've been using either CStrings (automatically taken care of) or string literals a la "Hello" which is implicitly null terminated.

I've been using the (EDIT: CWnd::SetDlgItemText) function, and I'm beginning to believe there may be some other issue here, especially since the larger memory leak only occurs when SetDlgItemText is commented in. I've commented out all code that even remotely relates to rendering or logic, and there is no dynamic memory being used anywhere in the program currently. Pretty much all I'm doing is handling an OnTimer event and updating all the edit controls in the dialog box.

Another strange occurance is that the Task Manager is showing jumps in my memory footprint when I do nothing but move the mouse inside the client area. I'm starting to wonder if these two issues may be related in some way, has anyone else noticed strange memory leaks in MFC Dialog based apps before?

ok, I'm assuming this issue is unique, but I'll give it one last bump.

I would point to CString or the temporary CWnd derived object created by many MFC methods.

MFC Objects are created queued in a special list, which is cleared in each OnIdle cycle.
If you are overriding the OnIdle method, you _must_ call the base method.
(And i think these leaks are hidden by the malloc_dbg parameter for MFC objects)

I could imagine this is the problem in your program.

NB: The performance counter does count in pages and not in memory. So you only see an per page increment. (Learned this the hard way, when dropping 4 Bytes per extremely lengthy operation.) So you may calculate the size of your leak.

Task Manager is NOT a good indicator of a problem either. Try putting in real memory management. I'll go with others and being 99.9% sure it's your code not the MS code in this case. It's likely in a totally different area. Anyways try sending the WM_SETTEXT message, it's how I do mine.

what type of control are you sending the text to? are you even sending 4 KB of data to that control every second? it seems too odd to be sending that much data to a standard windows control. is it a custom control? more info on the control would be helpful (that is, if it really truly is a problem with sending text to it and not something else in your program).

anyways for stuff like this GDI leaks are the most common problem. try looking at this page and run the GdiCount program for your tool's PID. if the count keeps going up and up and up, you got a GDI leak. if i recall right there's another tool on there that tells you which objects are bitmaps, fonts, ect. and will give you a clue on what to look for in your program.

[Edited by - yadango on December 30, 2006 1:44:45 AM]