[iOS] ViewCell's with nested layout are not garbage collected causing huge memory leak

[rodja]

Description

ViewCell's with nested layout (for example StackLayout with a ContentView) cause the whole ListView to be never destructed. The garbage collector seems unable to remove the ListView and it's ViewCells even though they are not referenced anymore.

Steps to Reproduce

Build and run this code:

public class App : Application
{
    public App()
    {
        MainPage = new NavigationPage(new ContentPage
        {
            Content = new Button
            {
                Text = "Show New ListView",
                Command = new Command(o => MainPage.Navigation.PushAsync(new ListPage())),
            },
        });
    }
}

public class ListPage : ContentPage
{
    public ListPage()
    {
        GC.Collect();
        Content = new ListView
        {
            ItemTemplate = new DataTemplate(typeof(Cell)),
            ItemsSource = new List<string> { "A" },
        };
    }
}

class Cell : ViewCell
{
    string guid = Guid.NewGuid().ToString();

    public Cell()
    {
        Console.WriteLine("Constructor " + guid);
        View = new StackLayout
        {
            Children = {
                new ContentView
                {
                    Content = new Label { Text = guid },
                }
            }
        };
    }

    ~Cell()
    {
        Console.WriteLine("Destructor " + guid);
    }
}

Open and close the page with the ListView a few times.

Expected Behavior

Destructor should be called.

Actual Behavior

ListPage, ListView and the Cells are never removed by the garbage collector causing huge memory leak.

Basic Information

• Version with issue: Xamarin.Forms 2.5 and 3.0-pre3
• Last known good version: none
• IDE: Visual Studio for Mack
• Platform Target Frameworks:
  • iOS: 11.2

[rodja]

Maybe this is similar to https://bugzilla.xamarin.com/show_bug.cgi?id=43941 where the garbage collector could not remove a Page with ListView when using ListViewCachingStrategy.RecycleElement.

[MelbourneDeveloper]

@rodja the lack of garbage collection is a big problem throughout all XAML based technologies. This is not just limited to controls that use DataTemplates. We logged this ticket: #1897. It's currently impossible to navigate to the same page twice. This is an issue because being able to navigate to the same page twice would be a great workaround for memory leak related issues. We want to recycle pages to save on performance, and more importantly reduce memory leakage.

Let me explain a bit more about the depth of the problem...

When objects are instantiated they are often enmeshed with other objects via property or event handler linkages. When objects become enmeshed with each other, the garbage collector will not destruct the object and all related objects will be left in memory. We're generally told things like ".NET is a managed runtime and the garbage collector will clean up after you", but the garbage collector will only do its job when all object references have been broken up. We're also told things like "Binding doesn't cause strong references to be held on to because XAML binding uses WeakReference". This is demonstrably not true in all cases.

Basically, as a rule of thumb, on any given control/page, in any given XAML technology, you need to take care to break up the object mesh when you are finished with an object. This means making sure event handlers are unhooked, and sometimes even bindings are undone. While a binding should only use a WeakReference, there is nothing to stop the code inside the control from hooking on to an object it is bound to when a BindableProperty/DependencyProperty is fired. This is relatively straight forward if you know which controls and objects have been created, but it becomes a lot more tricky when there are dynamically defined controls in DataTemplates, or dynamically rendered XAML (which is our case). When XAML is dynamically rendered, it's sometimes necessary to scan through the visual tree to find object linkages and manually break them. This is a huge performance problem. In each of our tabs (equivalent of Page) in Silverlight, we have to scan through the entire visual tree, and resources to ensure that no object has latched on to another object before the tab is removed from the screen. It creates visible lag.

There are many reasons why this particular problem might be occurring, but one of the largest problems we have is that objects will never get broken up because pages go on to the back stack and are never finalised. In our app, we're left in a situation where none of our controls will ever be destructed because 100% of the controls are attached to pages that are in the back stack. So, we are looking for a new strategy to deal with memory leakage in Xamarin Forms. My money is on page recycling. It's obviously the most straight forward way of dealing with the issue, but @jassmith has brought up issues that are associated with this.

We don't want to go down the same path we went down with Silverlight. We are still getting memory leaks in our Silverlight app even though we have meticulously designed the code in such a way that all object linkages are explicitly broken. We've wasted countless man hours trying to fix this issue, and users become exasperated when the app ends up crashing on them. It's simply not feasible to go down this same path with Xamarin Forms with three different platforms to debug. We've only managed to get the Silverlight app under control because we've had excellent profiling tools to work with that allowed us to find the needles in the haystacks.

So, I'd say that this issue is a part of a larger problem that needs to be addressed now. The issue is that there needs to be a recommended approach to memory management, and the XF platform needs to push us down this path so that we don't all run in to the same memory leak problems. Also, each XF control needs to be audited for memory leak issues on each platform, and automated tests need to be in place which ensure that through normal usage, controls don't leak memory.

@davidortinau you may be interested.

[rodja]

@MelbourneDeveloper thanks for the long response but it's hard to extract the facts from all that. Let me try:

• you have seen this problem a lot in your code base and tried to work around it by reusing pages (Bug 60966 - Can't Navigate To The Same Page Twice #1897)
• you think this issue is caused by enmeshing with other objects
• this enmeshing (as you call it) happens out of developer control simply by using XAML
• enmeshing can not be prevented

I hope this summary is sufficient. Maybe you can elaborate why this bug is caused by enmeshing with other objects. The example does not use XAML at all. And nothing is bound or subscribed to the DataTemplate. Do you think the iOS renderers are adding references which are not removed after popping the page? Why should it not be possible for Xamarin.Forms to clean up these references?

[MelbourneDeveloper]

@rodja , I've really just given an outline of the challenge that developers face when building any XAML based app - especially when controls can be defined dynamically within DataTemplates and so on.

you have seen this problem a lot in your code base and tried to work around it by reusing pages

Not exactly. In Silverlight, we have tried to detach all objects from their object linkages when we are finished with the pages. In hindsight, we have realised that this was a bad choice. We should have attempted to recycle the pages instead of breaking up the object mesh. Perhaps up to 10% of our UI codebase is dedicated to scanning through the visual tree, and unhooking event handlers and so on when pages are finished with, and yet, we still end up with very hard to find memory leaks in Silverlight. One classic problem is caused by a bug in the ContextMenu in Silverlight. To this day, wherever a ContextMenu is used, memory leaks will occur. We're still removing ContextMenus from our codebase

you think this issue is caused by enmeshing with other objects

I don't think. I know. The garbage collector cannot finalize an object if the object is connected to object still in scope. It's garbage collection 101.

this enmeshing (as you call it) happens out of developer control simply by using XAML

This is a bit of a loaded statement. What I am saying is that when controls or static resources are declared in XAML, they can latch on to other objects without the programmer knowing. This regularly happens in Silverlight, and care needs to be taken in Xamarin Forms to make sure the same thing doesn't happen. This bug is one example.

enmeshing can not be prevented

And nor should it. Object linkages are a normal part of object oriented programming. All we can do is make sure that the object linkages are broken when we are finished with the object by doing things like unhooking event handlers and so on. Or, by recycling objects that we are able to use again.

Do you think the iOS renderers are adding references which are not removed after popping the page?

It's impossible to speculate without digging in to the code.

Why should it not be possible for Xamarin.Forms to clean up these references?

It is usually possible. It's just very time consuming and difficult to make sure that all references are getting cleaned up.

At some point I will create a series of sample apps to show how easy it is to end up with a memory leak and log it as an issue. It's not so much that a programmer can't stop XF from leaking, it's that unless the programmer knows what they are doing, they are very likely to end up with scenarios that cause leaks. And moreover, every single control in the XF toolkit needs to be audited to make sure that it does not have memory leaks under differing scenarios. This bug is just one example of where the core toolkit can be leaking memory.

[PureWeen]

@rodja thank you very much for logging this one.

iOS renderers are adding references which are not removed after popping the page

Is the most likely culprit so now we're just isolating and figuring out the best way to fix

[MelbourneDeveloper]

@rodja , Hope I've missed something here but this might be another memory leak with ListView. I haven't tested on iOS though.

#2420