We've had problems with memory leaks in our application. I've managed to replicate one of the problems with the following simple example:
Replication setup
1) Create the following helper class which will be used to track object creation/destruction.
public class TestObject
{
public static int Count { get; set; }
public TestObject()
{
Count++;
}
~TestObject()
{
Count--;
}
}
2) Create an MDI form with three buttons, the first button will create a new MDI child as follows:
private void ctlOpenMDI_Click(object sender, EventArgs e)
{
Form newForm = new Form();
newForm.MdiParent = this;
newForm.Tag = new TestObject();
newForm.Show();
}
The second button will be used do the same, but with a non-MDI child form:
private void ctlOpenNonMDIForm_Click(object sender, EventArgs e)
{
Form newForm = new Form();
newForm.Tag = new TestObject();
newForm.Show();
}
The third button will be used to garbage collect and then display how many TestObject instances are live:
private void ctlCount_Click(object sender, EventArgs e)
{
GC.Collect();
GC.WaitForPendingFinalizers();
MessageBox.Show("Count: " + TestObject.Count);
}
Replication steps
1) Click Open MDI form button, then close the MDI form, then click the count button. It will return Count: 1. The MDI child form and the object it references was not garbage collected - something must still have a reference to it.
Also:
Click open MDI form three times, close all 3 forms, then click the count button. It will return Count: 1. It seems as though the last closed MDI child form is not garbage collected.
Counter-cases:
1) Click Open non-MDI form, close it. Then click the count button. It will return Count: 0, the form and object have been garbage collected.
Workaround
I can workaround this problem by doing this:
Form form = new Form();
form.MdiParent = this;
form.Show();
form.Close();
Before the garbage collection. This makes this dummy form the last closed MDI child form so that the other ones can be garbage collected - but why should I have to do this? What is going on?
Also it's a bit ugly as you will get a flicker of the form opening and closing, and it seems pretty hacky too.
The reason why this is happening is quite simple there is still a reference to this form. The good news is that we can remove this reference.
Add an eventhandler for the form closing event.
And a method to handle the event.
Here we reset the MdiParent property, by doing this the form is removed from the MdiChild list of the parent. Now when the form is closed this reference will reset as well.
Technically, because that
Form
is the "FormerlyActiveMdiChild". This looks like a bug. Fortunately, not a very serious one.The ability to troubleshoot uncollected objects is a good skill to have. The windbg debugger from Microsoft that comes with the Debugging Tools for Windows (http://www.microsoft.com/whdc/devtools/debugging/default.mspx) is great for this purpose. In the walkthrough below, note that I have removed a lot of the output from windbg that is not pertinent.
Form
, subclass it asTestChildForm
to make it easy to identify.!loadby sos mscorwks
.In windbg, run
!dumpheap -type TestChildForm
.Next, run
!gcroot 01e2e960
.Next, run
!dumparray -details 01e2ef04
and search the output for01e2e960
.Finally, I ran
!name2ee System.Windows.Forms.dll System.Windows.Forms.Form
followed by!dumpclass 6604cb84
(as determined by!name2ee
) and looked for 56.If you would rather use the Visual Studio debugger instead of windbg, you must first enable Properties, Debug, Enable unmanaged code debugging. Substitute
.load sos
for.loadby sos mscorwks
.