views:

312

answers:

2

I analyze a VB.NET project and there are some objects(child MDI form) that are disposed, but not removed by the GC.

The MemoryProfiler analysis find between others the following:

"This instance is disposed and still indirectly rooted by an EventHandler. This often indicates that the EventHandler has not been properly removed and is a common cause of memory leaks. The instances below are directly rooted by EventHandler(s). Investigate them to get more information about this issue..."

Now, I try to figure out what should this mean and how to fix it.

I have a MDI form and a child form. The child form is not collected by the GC after a open/close, apparently because remains still (indirectly?) referenced by the MDIForm EventHandlerList...

Any idea what it can be and how to fix it?

I tried the fix recommended in this thread, because had a problem with the MDI reference in the PropertyStore, now this eliminated, but appeared the MDI EventHandlerList reference to the child form...

EDIT:

After some code analysis I observed some

AddHandler newMenu.Click, AddressOf ClickMenu

without preceding with RemoveHandler newMenu.Click, AddressOf ClickMenu. Could it be the main cause?

And, a propos, is the Handles

Private Sub ClickMenu(sender as Object, e as EventArgs) Handles newMenu.Click

better that

RemoveHandler newMenu.Click, AddressOf ClickMenu
AddHandler newMenu.Click, AddressOf ClickMenu

from the memory allocation point of View?

+2  A: 

There is another object which references the object that should be removed by the GC via an eventhandler. Meaning: there's another object that is still subscribed to an event of the disposed object.

You can resolve this by unsubscribing from the event (remove the eventhandlers from the event), when you want to dispose that object.

Frederik Gheysels
+3  A: 

The EventHandlerList is used by classes that provide large numbers of events to more efficiently handle memory by only allocating space for the event backing field when it is needed rather than when the event is declared. All events for the main form are therefore stored there.

I would expect the child form was monitoring when its parent may close (this is a common use-case) and it didn't unsubscribe from the FormClosing or FormClosed event when it received that event. However, that's just a guess. To confirm, look at your child form implementation and find all cases where it subscribes to events from the parent form, then make sure there is a corresponding unsubscription from those events.

Update
The menu handler you found that was not removed could well be the root of the issue you see. Try adding the remove call and see if that addresses the leak.

Jeff Yates