Severe Memory Leaks
Hello all
I have a TabControl with dynamic tabs (Meaning the user open and close tabs).
When open the application the Memory usage size is 60MB
after open anew tab it goes to 63MB
When closing the new tab it goes to 63.4MB
after open anew tab it goes to 66.4MB
When closing the new tab it goes to 66.8MB
after open anew tab it goes to 69.8MB
When closing the new tab it goes to 70.2MB
and so on
so instead of getting down when closing it goes up in 400k.
in the clos sequence I set:
tabItem = null;
I even tried to use
GC.Collect();GC.WaitForPendingFinalizers();No luck....
Thank you for reproting this. I will try to reproduce the issue and see if there is a leak.
It will be useful if you post a simple repro and so we can work on it.
This is a huge solution with 11 Dll and combines Windows forms and WPF.
Before adding the WPF everything works fine in terms of memory management, I never tried to collect and never needed to.
After adding the WPF for enhanced user interface I encounter a lot of problems.
One of them is this memory leak issue, after half a day of working the memory reach reach to several hundreds of use even if all screens are closed. Eventually the application crash or the user is so tired that it works so slow that he restart the application.
what can I do.
can it be releated to the weak events things I see in other posts?
if it does, this is very annoying thing to do?
why isn't it implemented under the hood?
Any news on this? Were you able to get around it?
Thanks
h1 at 2007-9-12 >
If you're hosting Winforms content inside your WPF layout, are you manually Disposing of that content when you need to?
Also, posting a repro project should not be difficult. He's not asking you to post your actual application. If there's a leak relating to WPF/Winforms interop it should be quite easy for you to demonstrate this in a new simple application independent of your project.
OK I lost the patient to wait for an answer here so I looked a little bit in The web and send my team the next email:
(Found it on the web)
WindowsFormsHost:
Dispose
When mixing Windows Forms and WPF to make sure the ElementHost or WindowsFormsHost is disposed, or you could leak resources.Windows Forms will dispose an ElementHost when the non-modal Form it’s on closes; WPF will dispose a WindowsFormsHost if your application shuts down.(Really the interop-specific bit here is that you could show a WindowsFormsHost on a Window in a Windows Forms message loop and never get that your Application is shutting down.)
So make sure you dispose it when you need(like closing a dock manager tab)
?? ?????? ???? ?? ??? ???? ??? ????? ?? ?? ???
The last line in hebrew says to my workers:
"Only god knows what the guy who design it this way thought to himself...."
Now I am fighting for two days to manually dispose alooooooot of objects, finding myself totaly sorry for using WPF!!!!
If anyone come across this thread I warmly recommend to wait at least a year before using it on live apps.
Itzik
I am working a with a memory profiler app and I have two questions:
1. I am cleaning all WindowsFormsHost manually and they are all being disposed correctly except then one.
I am disposing each new WindowsFormsHost but I have some several more pointers using:
Code Snippet
WindowsFormsHost wfh = item.content as WindowsFormsHost; //(for example)
Do I need to dispose those as well, I do not think so but still have one live instance.
By the way most of the objects are being disposed but the memory keep rising, never go down.
2. I work with .net profiler, and seen a lot of undisposed objects almost 200 in the:
System.Windows.Media.Imaging BitmapSourceSafeMILHandle (211 211 0 211 0 0 0 0 188 188)
Is this OK that this object is not disposed correctly?
What can be the cause?
This is the code I use in several places to load image to Ribbon buttons:
Code Snippet
BitmapImage bi = new BitmapImage();
try
{
bi.BeginInit();
bi.UriSource = new Uri("pack://application:,,,/Resources/" + resourceName);
bi.EndInit();
img.Source = bi;
}
catch (InvalidOperationException exp)
{
VisualUtils.Dialogs.EBox.Show(exp, "????? ?????? ??????", "XWPFUtils",System.Reflection.MethodInfo.GetCurrentMethod().Name, "");
}
What can I do to load images correctly, assuming this is the problem?
thanks
Itzik
Solve iiiiiiiiiiiiiitttttttttt
Yes finally I can go back to real programming......`-))
OK
it is as the article says:
"When mixing Windows Forms and WPF to make sure the ElementHost or WindowsFormsHost is disposed, or you could leak resources.Windows Forms will dispose an ElementHost when the non-modal Form it’s on closes; WPF will dispose a WindowsFormsHost if your application shuts down.(Really the interop-specific bit here is that you could show a WindowsFormsHost on a Window in a Windows Forms message loop and never get that your Application is shutting down.)"
But before disposing the WindowsFormsHost in several cases you should clear the UIElement that contains it for example the Grid:
Code Snippet
grdMain.Children.Clear();
_statusHostBar.Dispose();
the indication for that is that you see objects like Borders, Row collection..... still holding the WFI instance and basically your WF control.
Itzik
I'm using the CLRProfiler to figure out why my exe uses so much memory. The clrprofiler is reporting that these <root> is using 14 mb. But when I go through the same set of steps, the windows task manager is reporting that the exe is using 75 mb. Is that normal?
Thanks
h1 at 2007-9-12 >
Hi I.Katzav,
To solve this problem you should remove the tabItem instead of setting it to null.
For example, if you are trying to remove the tabItem at index 0, you may do the following
tabControl.Items.RemoveAt(0);
Hope this helps!
Shozub.
Thanx
I actually do remove the TabItem. Eventually in order to avoid those so called memory leaks you just need to dispose or clear any collection or object that holds a reference to the windows forms host. Disposing the WindowsFormsHost itself is not enough.
But thanx anyway
Itzik
Although calling dispose helps when it comes to unmanaged resources, always be sure to remove references to unused objects/ui elements/etc. in .NET. It doesn't matter that there's a Dispose as Itzik mentioned. They still may be rooted elsewhere, in collections as children, Dictionaries, etc. Sometimes, it helps to break out WinDbg and the SOS.dll to track them down if a profiler doesn't work.
