Pinned Instances for GC - Not traceable from my managed code

Question

So I am using WPF 3.5 with MVVM + DataTemplate method to load 2 views on the GUI. I have observed while memory profiling that items generated as part of items container of items controls are pinned into the memory and doesn't get GCed even after the view is unloaded!

I just ran tests and found out it is reproducible even for the simplest of code... You guys can check for yourself.

XAML:

<Window x:Class="ContentControlVMTest.Window2"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="clr-namespace:ContentControlVMTest"
        Title="Window2" Height="300" Width="300">
    <DockPanel LastChildFill="True">

        <CheckBox Click="CheckBox_Click" Content="Test1?"
                  DockPanel.Dock="Top" Margin="5"/>

        <ContentControl x:Name="contentControl">
            <ContentControl.Resources>

                <DataTemplate DataType="{x:Type local:Test3}">
                    <TextBlock Text="{Binding C}" Margin="5"/>
                </DataTemplate>

                <DataTemplate DataType="{x:Type local:Test1}">
                    <DockPanel LastChildFill="True" Margin="5">
                        <TextBlock Text="{Binding A}"
                                   DockPanel.Dock="Top"
                                   Margin="5"/>
                        <ListBox ItemsSource="{Binding Bs}"
                                 DisplayMemberPath="B"
                                 Margin="5"/>
                    </DockPanel>
                </DataTemplate>
            </ContentControl.Resources>
        </ContentControl>
    </DockPanel>
</Window>

Code Behind:

public class Test3
{
    public string C { get; set; }
}

public class Test2
{
    public string B { get; set; }
}

public class Test1
{
    public string A { get; set; }

    private List<Test2> _Bs;
    public List<Test2> Bs
    {
        get
        {
            return _Bs;
        }

        set
        {
            _Bs = value;
        }
    }
}

public partial class Window2 : Window
{
    public Window2()
    {
        InitializeComponent();
        this.KeyDown += Window_KeyDown;
    }

    private void Window_KeyDown
            (object sender, System.Windows.Input.KeyEventArgs e)
    {
        if (Keyboard.IsKeyDown(Key.LeftCtrl))
            if (Keyboard.IsKeyDown(Key.LeftShift))
                if (Keyboard.IsKeyDown(Key.LeftAlt))
                    if (Keyboard.IsKeyDown(Key.G))
                    {
                        GC.Collect(2, GCCollectionMode.Forced);
                        GC.WaitForPendingFinalizers();
                        GC.Collect(2, GCCollectionMode.Forced);
                        GC.WaitForPendingFinalizers();
                        GC.Collect(3, GCCollectionMode.Forced);
                        GC.WaitForPendingFinalizers();
                        GC.Collect(3, GCCollectionMode.Forced);
                    }
    }

    private void CheckBox_Click(object sender, RoutedEventArgs e)
    {
        if (((CheckBox)sender).IsChecked.GetValueOrDefault(false))
        {
            var x = new Test1() { A = "Test1 A" };
            x.Bs = new List<Test2>();
            for (int i = 1; i < 10000; i++ )
            {
                x.Bs.Add(new Test2() { B = "Test1 B " + i });
            }
            contentControl.Content = x;
        }
        else
        {
            contentControl.Content = new Test3() { C = "Test3 C" };
        }
    }
}

I perform forced GC by Left Shift + Alt + Ctrl + G. All items for the Test1 or Test3 view and View Model gets dead after they are unloaded correctly. So that is as expected.

But the collection generated in the Test1 model (that has Test2 objects), remains pinned into the memory. And it indicates that the array is the one used by the items container of the listbox because it shows the number of de-virtualized items from the listbox! This pinned array changes it's size when we minimize or restore the view in Test1 view mode! One time it was 16 items and next time it was 69 item when profiled.

This means WPF performs pinning of items generated in items controls! Can anyone explain this? Does this have any signficant drawback?

Thx a lot.

Answer 1

The problem is being caused by a failure of the binding mechanism to fully release the list items that have actually been bound for display on the screen. That last bit is almost certainly why you're seeing different numbers of "orphaned" instances in different runs. The more you scroll the list, the more problems you generate.

This seems to be related to the same sort of underlying problem as described in a bug report that I submitted over a year ago since the pinning root and pinned instance trees are similar. (To see that kind of detail in a convenient format, you might want to grab a copy of a somewhat fancier memory profiler like ANTS Memory Profiler.)

The really bad news is that your orphaned instances are being pinned past the demise of the window itself, so you probably can't clean them up without the same sort of hack I had to use in the WinForms scenario to force clean-up of the binding privates.

The only bit of good news in all this is that the problem does not occur if you can avoid binding to nested properties. For example, if you add a ToString() override to Test2 to return the value of its B property and remove DisplayMemberPath from you listbox item, the problem will go away. e.g.:

public class Test2
{
    public string B { get; set; }

    public override string ToString()
    {
        return this.B;
    }
}

---

<ListBox ItemsSource="{Binding Bs}" 
    Margin="5"/>