Resource Leak
in [MFC]
|
From: jc on 25 May 2010 12:19 Hello, I am developing a 64-bit MFC application using VC2008. I have a method, that once a user clicks a button, the "File Open" dialog box is displayed. The dialog box variable is declared locally in the method. I noticed (using Task Manager), that once the dialog box opens, the application memory usage increases from 3 MB to 30 MB, but when the dialog box is closed, the memory usage does not decrease. Since, the dialog box variable is declared locally, shouldn't the memory decrease, because the dialog box variable is no longer in scope? Is the application leaking? TIA, -jc
From: David Ching on 25 May 2010 12:47 "jc" <jc(a)discussions.microsoft.com> wrote in message news:78AE1A30-9259-4C79-A329-AA8749266852(a)microsoft.com... > I noticed (using Task Manager), that once the dialog box > opens, the application memory usage increases from > 3 MB to 30 MB, but when the dialog box is closed, the > memory usage does not decrease. Since, the dialog box > variable is declared locally, shouldn't the memory decrease, > because the dialog box variable is no longer in scope? > > Is the application leaking? > Not necessarily. The Open File dialog is a Windows system dialog whose resources and code are in a Windows DLL. When you first show it, Windows loads this DLL and instantiates the dialog. But when the dialog is closed, Windows might not be aggressive about unmapping the DLL from your process, or even reclaiming the instance memory of the dialog (it might just mark it as unused and available for a subsequent allocation). To make Windows aggressively reclaim as much memory as possible, call SetProcessWorkingSetSize((SIZE_T) –1, (SIZE_T) –1) as stated in http://msdn.microsoft.com/en-us/library/ms686234%28VS.85%29.aspx I believe this is called for you if you minimize your window, so if you minimize the dialog, you can achieve the same thing without adding any code. -- David
From: Tom Serface on 25 May 2010 19:01 That's difficult to tell from task manager. If you leave it sit for a while and then do a refresh you should see the memory being returned, but often Windows caches the memory thinking you may call the same functionality again. I think the memory indicators in Task Manager are interesting, but not a good indication of what is really happening in your program alone. Tom "jc" <jc(a)discussions.microsoft.com> wrote in message news:78AE1A30-9259-4C79-A329-AA8749266852(a)microsoft.com... > Hello, > > I am developing a 64-bit MFC application using VC2008. > I have a method, that once a user clicks a button, > the "File Open" dialog box is displayed. The dialog > box variable is declared locally in the method. > > I noticed (using Task Manager), that once the dialog box > opens, the application memory usage increases from > 3 MB to 30 MB, but when the dialog box is closed, the > memory usage does not decrease. Since, the dialog box > variable is declared locally, shouldn't the memory decrease, > because the dialog box variable is no longer in scope? > > Is the application leaking? > > TIA, > -jc
From: Giovanni Dicanio on 26 May 2010 05:33 "David Ching" <dc(a)remove-this.dcsoft.com> wrote: > "jc" <jc(a)discussions.microsoft.com> wrote in message >> I noticed (using Task Manager), that once the dialog box >> opens, the application memory usage increases from >> 3 MB to 30 MB, but when the dialog box is closed, the >> memory usage does not decrease. > > [...] >> Is the application leaking? >> > > Not necessarily. The Open File dialog is a Windows system dialog whose > resources and code are in a Windows DLL. When you first show it, Windows > loads this DLL and instantiates the dialog. But when the dialog is > closed, Windows might not be aggressive about unmapping the DLL from your > process, or even reclaiming the instance memory of the dialog (it might > just mark it as unused and available for a subsequent allocation). Considering the 30 MB increase, a guess may be that there is some .NET shell-extension loaded. In fact, shell extensions are injected in all processes that use the shell namespace, and that can happen as a consequence of GetOpenFileName call as well. So, the open file dialog may load the CLR (.NET runtime) because there might be some .NET shell-extension installed in the system, and this may justify the 30 MB increase. Not sure about that, but just an "educated guess". Giovanni
From: David Ching on 26 May 2010 11:24
"Goran" <goran.pusic(a)gmail.com> wrote in message news:eaf0f835-5187-4b03-9e93-287a2e9ef72d(a)a16g2000vbr.googlegroups.com... > AFAIK, MS effectively says: "don't write shell extensions in .NET. > Instead, write a stub for the extension in native code, then call out > to a .NET *.exe". Problem being that (at the time I saw this, but > possibly now as well), only one instance of .NET runtime could run > within on process. But if extension A needs .NET version X, and > extension B needs ,NET Y, then what? Hence the advice. > With VS 2010 and .NET 4, you can now write shell extensions in .NET. > But said "split the extension" advice is sound for native code as well > - who wants his explorer.exe sucking in who knows how much stuff (for > all in-proc extensions system might have), when most of it is needed > for a couple of seconds, time to time? > Yup! -- David |