CodePlex
Open Source Community
Register | Sign In | CodePlex Home
Search
40
votes
ContextMenu causes memory leak

Description

ContextMenu subscribes MouseMove event in ContextMenu.InitializeRootVisual, but it won't unsubscribe it, and it don't use WeakEvent. So it won't be GCed after it is unloaded. I verified the leak in Windbg, sample !gcroot result:

DOMAIN(063DF7F0):HANDLE(Pinned):6b612f8:Root: 07d64260(System.Object[])->
06d96964(SAPStudio.I264Player.SilverlightGui.MainPage_3)->
06d96a2c(MS.Internal.CoreTypeEventHelper)->
06d96a98(System.Collections.Generic.Dictionary`2[[System.Int32, mscorlib],[MS.Internal.CoreTypeEventHelper+EventAndDelegate, System.Windows]])->
07907da0(System.Collections.Generic.Dictionary`2+Entry[[System.Int32, mscorlib],[MS.Internal.CoreTypeEventHelper+EventAndDelegate, System.Windows]][])->
0765c110(MS.Internal.CoreTypeEventHelper+EventAndDelegate)->
0765c0d8(System.Windows.Input.MouseEventHandler)->
*** 0764ce5c(System.Windows.Controls.ContextMenu) ***->
0764de04(System.Windows.Controls.ItemCollection)->
07650ee0(System.Collections.Generic.Dictionary`2[[System.Windows.UIElement, System.Windows],[System.Object, mscorlib]])->
07650f2c(System.Collections.Generic.Dictionary`2+Entry[[System.Windows.UIElement, System.Windows],[System.Object, mscorlib]][])->
0764ec38(System.Windows.Controls.MenuItem)->
0764ecc0(MS.Internal.CoreTypeEventHelper)->
0764f4d8(System.Collections.Generic.Dictionary`2[[System.Int32, mscorlib],[MS.Internal.CoreTypeEventHelper+EventAndDelegate, System.Windows]])->
0764f524(System.Collections.Generic.Dictionary`2+Entry[[System.Int32, mscorlib],[MS.Internal.CoreTypeEventHelper+EventAndDelegate, System.Windows]][])->
0764f4c8(MS.Internal.CoreTypeEventHelper+EventAndDelegate)->
0764f490(System.Windows.RoutedEventHandler)->
0764f318(System.Windows.Data.BindingExpression)->
0764f144(SAPStudio.I264Player.SilverlightGui.Interactivity.ClipboardCommands.CopyCommand)

File Attachments

No files are attached

Comments

nico008 wrote Feb 13 at 2:54 PM
Sorry, I missed anilchinnu21's post.
His link solved two big memory leak I had.

Great work!

I hope this will be in next Toolkit release

nico008 wrote Feb 13 at 8:37 AM
Anyone has a better solution than patch ID 7215?
I don't like much having to call something from OnNavigatedFrom...

Note : this issue should have medium or high impact since this cause all my pages not GCed -> my app reach GBs after some hours.

anilchinnu21 wrote Sep 25 2011 at 11:19 AM
Below is the ultimate solution that we found after looking into the codeplex community forum threads.

http://www.dotnetthread.com/articles/6-SolutiontoMemoryleakissueswithSilverlightcontroltoolkit.aspx

anilchinnu21 wrote Sep 25 2011 at 11:18 AM
Below is the ultimate solution that we found after looking into the codeplex community forum threads.

http://www.dotnetthread.com/articles/6-SolutiontoMemoryleakissueswithSilverlightcontroltoolkit.aspx

yifung wrote Jun 22 2011 at 7:35 PM
You can try the attachment in workitem 6206
http://silverlight.codeplex.com/workitem/6206

jcheung wrote Jun 17 2011 at 2:30 AM
I also believes that the impact of this issue should be HIGH.

trenttobler wrote May 11 2011 at 1:31 PM
We encountered this bug too, but took a slightly different tact -- we used a weak event listener pattern. Instead of:

if (null != _rootVisual)
{
// Ideally, this would use AddHandler(MouseMoveEvent), but MouseMoveEvent doesn't exist
_rootVisual.MouseMove += new MouseEventHandler(HandleRootVisualMouseMove);
}

we used:
if (null != _rootVisual)
{
var rootVisual = _rootVisual;

// Use a weak event listener.
var rootVisualMouseMoveListener = new WeakEventListener<ContextMenu, object, MouseEventArgs>( this );
rootVisualMouseMoveListener.OnEventAction = ( instance, source, eventArgs ) => instance.HandleRootVisualMouseMove( source, eventArgs );
rootVisualMouseMoveListener.OnDetachAction = ( weakEventListener ) => rootVisual.MouseMove -= weakEventListener.OnEvent;
rootVisual.MouseMove += rootVisualMouseMoveListener.OnEvent;
}

Probably the existing patches are better if they in fact track the context menu lifecycle and explicitly detach, rather than waiting for the event to trigger. When we evaluated this, we decided to just keep the weak event listener since we had already done testing and found it to fix the leak.

dksimon wrote Apr 20 2011 at 5:56 PM
If adventful's patch just removes the handler when it is unloaded, how will this work if the ContextMenu is in a TabControl? The Loaded/Unloaded events get called any time you switch tabs, this would seem to break it if I switch away from a tab that has a ContextMenu and back.

Thraka wrote Apr 20 2011 at 5:14 PM
Why is the impact on this Low? This should be High!

rehansaeed wrote Feb 24 2011 at 9:23 AM
This bug makes the ContextMenu unusable for me. If you use it on any page with a few images then eventually the application will crash out because there is no memory left. The two patches are useful but they require you to remove the ContextMenu when navigating away from the page. In my case this is very difficult as I am using the ContextMenu from within a ListBox's DataTemplate.

adventful wrote Jan 22 2011 at 6:11 AM
I also submitted a patch for this (8163) - didn't find this issue or Mendoza32's patch until I'd already made the fix, so I figured I might as well add mine as well.

Mendoza32 wrote Oct 29 2010 at 8:57 AM
I've uploaded simple fix for this issue. Look for patch ID 7215 in http://silverlight.codeplex.com/SourceControl/PatchList.aspx

Sign in to add a comment or to set email notifications
Updating...
© 2006-2012 Microsoft | Get Help | Privacy Statement | Terms of Use | Code of Conduct | Advertise With Us | Version 2012.2.15.18416