DataGrid using VSM causing memory leak??

Feb 27, 2009 at 6:59 PM
Edited Feb 27, 2009 at 7:03 PM
I initailly submitted this as a issue, but maybe I'm just doing something wrong.

To reproduce the problem, I started with Vincent Sibal’s sample on using VSM with the DataGrid

And I made the following changes:
1) Removed the WPFToolkit project and replaced it with a reference to the 3.5.40128.1 dll
2) Added a button to force garbage collection
3) Modified Window1 so it allocates 100MB of memory when it is instantiated
4) Added Window2, which is an exact copy of Window1 except I removed RowStyle="{DynamicResource defaultRowStyle}" from the DataGrid
5) Added an OnDetatch override to DataGridRowBehavior

I cannot attach a file tro this post, but you can download the project from the issue.

When you run the application, click the “Window1” button and you will see the memory jump up by 100MB. Close Window1 and click the “Garbage Collect” button. The memory allocated for Window1 does not get collected.

Now click the “Window2” button to show the Window that does not have the RowStyle set. Again you will see the 100MB get allocated. Close Window2 and click the “Garbage Collect” button. This time the allocated memory is collected.

The only difference between the two windows is the use of VSM.

Here is my implementation of OnAttach and OnDetach, perhaps I'm missing something there?

 

private EventHandler handler = null;

protected override void OnAttach(Control control)

   base.OnAttach(control);
   DataGridRow dataGridRow = (DataGridRow)control;
   Type targetType = typeof(DataGridRow);
   handler =
delegate { UpdateState(dataGridRow, true); };
   AddValueChanged(
DataGridRow.IsMouseOverProperty, targetType, dataGridRow, handler);
   AddValueChanged(
DataGridRow.IsSelectedProperty, targetType, dataGridRow, handler);
   AddValueChanged(
DataGridRow.IsEditingProperty, targetType, dataGridRow, handler);
}

protected override void OnDetach(Control control)  
{
   base.OnDetach(control);
   DataGridRow dataGridRow = (DataGridRow)control;
   Type targetType = typeof(DataGridRow);
   RemoveValueChanged(
DataGridRow.IsMouseOverProperty, targetType, dataGridRow, this.handler);
   RemoveValueChanged(
DataGridRow.IsSelectedProperty, targetType, dataGridRow, this.handler);
   RemoveValueChanged(
DataGridRow.IsEditingProperty, targetType, dataGridRow, this.handler);
}

 

 

Coordinator
Feb 27, 2009 at 10:01 PM
Hi, this sounds very similar to a memory leak we had in VSM that we fixed in the new version of the WPFToolkit.  I'll try to investigate this further and see what the problem could be.

Regards,
Saied K
Mar 3, 2009 at 10:11 PM
Hi Saied, did you have luck tracking this down?

Thanks
John
Coordinator
Mar 26, 2009 at 9:24 PM
Hi John,

Vincent made a suggestion on the issue tracker.  He said that this is because the DataGridRowBehavior class was not updated to implement the OnDetach protected method for that particular behavior class. Once the events are detached it should eliminate the memory leak, as it has with the other controls.  If the memory leak persists after this modification, it is likely but improbable that it's related to VSM.

The release of VSM through the WPFToolKit was meant to introduce people to the feature and also to shorten the compatibility gap between Silverlight and WPF.  We're aware of the suggestions that people such as yourself have made regarding this feature, and we've been working to enhance VSM and integrate it into the .NET 4.0 framework.  The VSM in the .NET 4.0 release no longer relies on behavior classes and therefore eliminates any issues regarding memory leaks that it has had in the WPFToolKit.  John, if the fix above still causes VSM memory leaks then I personally suggest adopting this feature from the .NET 4.0 framework release.

Hope that helps,
Saied Khanahmadi
Mar 26, 2009 at 9:36 PM
Thanks Saied -

I tried implementing OnDetach, but that did not fix the leak.  The second file I posted in the issue demonstrates the leak with OnDetach implemented (assuming I implemented it correctly).  I'll keep messing with ii a little, but it looks like I will have to wait for 4.0.
John