We are using the drag drop manager in some of our xaml view pages and believe there are memory leaks caused by the Infragistics drag drop framework. We are using WinDbg to track the leak down. Here is the output from WinDbg when inspecting the heap after the suspect page has closed:
------------------------------------------------------------------------------------------------------------------------------------------
0:031> !dumpheap -type Infragistics.Silverlight.Controls.XamWebTileView
Address MT Size
07f1083c 0a27f510 136
07fe6aac 0a27f510 136
08092e70 0a27f510 136
081395f8 0a27f510 136
081fb45c 0a27f510 136
082cb060 0a27f510 136
total 6 objects
Statistics:
MT Count TotalSize Class Name
0a27f510 6 816 Infragistics.Silverlight.Controls.XamWebTileView
Total 6 objects
0:031> !gcroot 082cb060
Note: Roots found on stacks may be false positives. Run "!help gcroot" for
more info.
Scan Thread 0 OSTHread bf4
Scan Thread 14 OSTHread 670
Scan Thread 15 OSTHread 17d8
Scan Thread 16 OSTHread 1930
Scan Thread 17 OSTHread 1e08
Scan Thread 29 OSTHread 1324
DOMAIN(04FFE508):HANDLE(Pinned):16212f0:Root: 08dfd080(System.Object[])->
07f370b4(Infragistics.Silverlight.DragDropManager)->
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
We are setting up the drag drop on the Loaded events of various elements in DataTemplates e.g:
private void ClassDataTemplateBorder_Loaded(object sender, RoutedEventArgs e)
{
(sender
as Border).Loaded -= ClassDataTemplateBorder_Loaded;
DragSource dragSource = new DragSource { IsDraggable = true };
dragSource.Drop -= DragSource_Drop; dragSource.Drop += DragSource_Drop;dragSource.DragStart -= DragSource_DragStart;dragSource.DragStart += DragSource_DragStart;
DragDropManager.SetDragSource(sender as Border, dragSource);
}
Are there known memory leaks with either the Drag drop framework or XamWebTileView?
Hi deta,
It's possible because the DragSource/DropTarget instance keeps reference of the UIElement it is attached to. When the dragged object is destroyed (the data is removed from collection and that will produce that the UIElement is removed) you need to detach from this UIElement the previously attached DragSource or DropTarget instances.
When DragEnd event is fired your event handler needs to contains these two lines (the second one is needed only when the same UIElement is also used as drop target)
private void OnDragEnd(object sender, DragDropEventArgs e)
DragDropManager.SetDragSource(e.DragSource, null);
DragDropManager.SetDropTarget(e.DragSource, null);
There is known leak that’s fixed but the fix will be available with next service release. After the detaching there will be one instance still standing captured.
What you can do now is to put this line of code next to the previous two lines in DragEnd event handler:
...
DragDropManager.DragPopup.Child = null;
That should fix the leaks but if there are still instances alive, after the detaching and popup’s child clean-up, let me know and I’ll try to track them.
Best regards.
This won't fix the problem as the memory leak occurs even when I don't perform any drag and drop operations on the page. I can test the page simply by inserting a large byte array in the constructor e.g.
test = new byte[100 * 1024 * 1024];
I then open and close the page continuously. Now I can see the memory consumption growing and growing until the browser crashes. We know that the Infragistics controls are the culprit from the Windbg output:
0:031> !dumpheap -type Infragistics.Silverlight.Controls.XamWebTileView Address MT Size07f1083c 0a27f510 136 07fe6aac 0a27f510 136 08092e70 0a27f510 136 081395f8 0a27f510 136 081fb45c 0a27f510 136 082cb060 0a27f510 136 total 6 objectsStatistics: MT Count TotalSize Class Name0a27f510 6 816 Infragistics.Silverlight.Controls.XamWebTileViewTotal 6 objects0:031> !gcroot 082cb060Note: Roots found on stacks may be false positives. Run "!help gcroot" formore info.Scan Thread 0 OSTHread bf4Scan Thread 14 OSTHread 670Scan Thread 15 OSTHread 17d8Scan Thread 16 OSTHread 1930Scan Thread 17 OSTHread 1e08Scan Thread 29 OSTHread 1324DOMAIN(04FFE508):HANDLE(Pinned):16212f0:Root: 08dfd080(System.Object[])-> 07f370b4(Infragistics.Silverlight.DragDropManager)->
Quite frankly I am amazed that a company can release products when there are known memory leaks! Does your company actually test their products before a release? Very shoddy.
Can you provide the code sippet please.
Thanks.