Possible hoding on the memory on DataGrid?

Hi There,

I have a usercontrol and it holds a datagrid and other controls. The DataGrid's ItemsSourve is binding to a BindingList, and other controls such as ListBox also bind to the different BindingList. When this user control does not need anymore, it does not get ready for GC collection, because the DataGrid still holds on some reference (while the other controls in the same user control does not ). Here are the things that Red-Gate Ants memory profile shows us:

WpfDataGrid.RowIsExpandedChangedEventArgs Event handler holds on something that does not get released.(From the memory profiler, the WpfDataGrid.RowIsExpandedChangedEventArgs holds a reference to the DataGrid).

Please help us since we use this DataGrid all over the places in our application.

Thanks

Gordon

Hello Gordon

I will look into this first thing tomorrow.

Jason Fauchelle

Thanks Jason, Also Lengend Item in chart also holding up the memory to prevent GC to do the job.

Thanks Gordon

Hello Gordon

Unfortunately I was unable to reproduce the memory issue with the DataGrid. I used the Red Ants memory profiler and from my tests found that the DataGrid instance disappears as expected. Keep in mind that since the DataGrid is a much heavier control than other controls, it can take some time before the GC fully collects it. Try waiting a little longer and take a few more memory snapshots in the profiler to see if things change over time. If there is still an issue, please send us a repro project for us to look into it further. There may be a particular feature you are using causing the memory issue which I would not be able to find without a repro.

Thanks for pointing out the Chart memory leak. This one I was able to reproduce, track down and resolve. A fix for this will be available in the next nightly build.

Jason Fauchelle

Hi Jason, We are extremely too busy to make up a reproducible project, but I send you the file saved from Red Gate.

The things needed to make a reproduce project is to:

1) On a window, need to add a tree with at least 2 tree nodes and list of usercontrols 2) Put dataGrid onto UserControl and binding them to a BindingList 3) Click on different tree node you will load different user control at same time remove the user control from window list collection 4)then do a memory profile and you can see the UserControl is holded up by the DataGrid

Thanks

Gordon

Hi Jason,

I also tried to profile your samples and find also it holds up the control for GC: 1) Run Sample

2) Go to DataGrid Hierarchical Data demo

3) Click on next button to different page (at this point DataGridHierarchicalDataDemo should be free for GC, since nobody holds on to it).

4) Do a memory snap shot

5) go to Class List and see class DataGridHierarchicalDataDemo for meory info "Instance Retention Graph"

Hope this will help you nail it down. (I am using April 2 nightly builds)

Thanks

Gordon

Hello Gordon

I still have not been able to reproduce this. Our Sample Explorer produces quite a different scenario than the one in your profiler results. The Sample Explorer doesn't let go of the views as it should. This is a bug in the application not the DataGrid.

I also tried the repro steps you proposed, but the DataGrid is removed from memory. From the profiler results I have not been able to pinpoint anything in the DataGrid that could be causing this. In your application, are you holding on to the DataGrid.DisplayedItemsSource? Possibly through some kind of CollectionView?

Jason Fauchelle

Thanks Jason,

I did not use DisplayedItemsSource at all, If you change the sample to let it go of the view, will it work? Since when I navigate the views the view is recreated everytime you go to the page.

Can you send me the samples you tried to reproduce so I can see if I can reproduce?

Thanks

Gordon

Hi Jason, I did something more on sample explorer. If I comment out the DataGrid part in the xaml as:

<local:DemoDisplay x:Class="SampleExplorer.DataGridHierarchicalDataDemo"
                   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                   xmlns:local="clr-namespace:SampleExplorer"
                   xmlns:ms="http://namespaces.mindscape.co.nz/wpf">
  <!--<local:DemoDisplay.DemoContent>
    <ms:DataGrid ItemsSource="{Binding Data}" ItemTemplate="{ms:ChildPath Employees}">
      <ms:DataGrid.Columns>
        <ms:DataGridColumn PropertyName="Role" Width="200" />
        <ms:DataGridColumn PropertyName="Salary">
          <ms:DataGridColumn.DisplayTemplate>
            <DataTemplate>
              <TextBlock Text="{Binding Salary, StringFormat=C}" VerticalAlignment="Center" Margin="2,0,0,0" />
            </DataTemplate>
          </ms:DataGridColumn.DisplayTemplate>
        </ms:DataGridColumn>
      </ms:DataGrid.Columns>
    </ms:DataGrid>
  </local:DemoDisplay.DemoContent>-->
</local:DemoDisplay>

Then doing the following steps:

1) Run Red gate profile

2) Navigate to Hierachical Data View

3) Take a memory snapshot

4) You can see for class DataGridHierarchicalDataDemo, it is not ready for GC, because it is in view

5) Navigate to other view

6) Take a snapshot again and check class DataGridHierarchicalDataDemo, it is ready for GC, because it is not in the view, which is good. (if the class does not exist in the profiler's class list, it means it is already get cleaned up, which is good)

This proves your sample explorer program does not have problem for release the memory.

Ok, uncomment the code and repeat steps 1) through 6). You will find on step 6), that, this time, the DataGridHierarchicalDataDemo, it is not ready for GC, because it's datagrid holds on something.

Also if you just comment out the databinding part on the DataGrid, repeat steps 1) to 6), also it is free for the DataGridHierarchicalDataDemo to be GC collected. This means the DataGrid binding has problem to hold up the memory.

Since I still did not have time to construct a sample reproducible project, can you work on this and try to solve them?

Some hint is that if you register any event handler you need to unregister it for the memory to release.

By the way, the Chart part memory leak is fixed.

Thanks

Gordon

Hello Gordon

Thanks for the repro steps, but unfortunately this still indicated the memory leak is in the Sample Explorer app. I have resolved this issue in the Sample Explorer and the profiler now shows that the DataGrid is collected correctly. This will be available in the next nightly build.

In any case, it will be best to work on a repro project rather than the Sample Explorer as the leak may be application specific. I have attached my memory test app that I was using to try reproduce this issue. See if you can find something that you're doing that I have missed from this app. Feel free to modify the application to try reproduce the issue.

A couple of pointers that may or may not help: Taking an extra 1 or 2 memory snapshots in the profiler can sometimes change the results - almost as though the GC was being delayed but then re-run when an extra snapshot is taken. It sounds strange, but I have seen it many times. This would indicate that there actually isn't a memory leak. Also, make sure that any non-DependancyObjects in your model that is used in the DataGrid implements INotifyPropertyChanged even if it doesn't need to raise property changed events. (From your profiler results this doesn't look like the issue, but it's worth checking it out).

Jason Fauchelle

Thanks a lot Jason for posting testing project. After a little changes on project settings, I can reproduce the problem that we have.

1)We set the project's property so that it uses .Net 4.0, rebuild the project

2)Start memory profiler

3)click on item2 in the tree

4)Take a snapshot

5) look the class DataGridControl for memory, it points to the Mindscape.WpfElements..WpfDataGrid.DataGridItemsSource and WpfDataGrid.RowIsExpandedChangedEventArgs holding up something that cannot be released.

I knew that the WpfElement is build upon on .Net 3.5, and our application is using .Net 4.0. But we went too far in our application so that we cannot switch back to .Net 3.5. Please help us to clean up the memory issue since we are in the final stages of release...

If we switch back to use .Net3.5 then, the DataGridControl will not be in memory if we go through the steps from 1) to 5).

Please help and help!!!!

Desparate Developer Gordon

Hi Jason,

Any progress on this? Or you cannot reproduce it?

I know this is hard one to solve, as long as I can get fixed version by the end of April, I will be very happy about it.

Thanks Gordon

Hello Gordon

Thanks for working out how to reproduce the problem in the sample app. I was able to reproduce the issue and have finally found and implemented a solution to this. The fix will be available in the next nightly build. This works in the sample app, and resolves the issue indicated in the memory profile you sent, but let me know if your main app still holds onto the DataGrid. If so, send me a new memory profile.

Jason Fauchelle

Thanks a lot, Jason, and Cannot wait to get build... Will let you know the results tomorrow

Gordon

Kudos to you and your team, Jason. The memory leak is fixed, any word how do you fix them?

Hi Jason,

Since the fix (I downloaded Apri 17th Nightly build), Did you put some code on DataGrid.OnLoad events?

We found a big problem though:

if we put the DataGrid on to ActiPro's Mdi Tabs and switch the tabs it will call Control's unloaded events. If we put some clean up on that events, then when we switch it back to the previous tab, the contents on that control is gone.

in our case, the DataGrid will show nothing and seems that itemsSource is nothing there? But when we check the ItemsSource, it is there and just cannot show the records on the datagrid (columns are there though).

Can you fix them?

Thanks, Gordon

Thanks for pointing this out Gordon.

As you may have worked out, the memory leak was resolved by listening the the Unloaded event and detaching or destroying different parts of the DataGrid to release the memory. This is a problem for tab controls and some other scenarios because the DataGrid can be unloaded and then loaded again multiple times in its lifetime. I've minimized the destructive process so that the various parts can quickly be restored again if the control is reloaded. This will be resolved in the next nightly build. Let me know if there is still a DataGrid memory leak in your application.

Jason Fauchelle

Seems ok for April 18, 2013 nightly build. But I am not so confident though. Is all this fixes going to be in version 6.0?

Yes, they will be included in version 6.0.