Xamarin.forms: [Android, iOS] NavigationPage.PopAsync() cause memory leak by still holding on popped Page

[davidortinau]

Migrated from https://bugzilla.xamarin.com/show_bug.cgi?id=31171

Description

Found with profiler that Task holds popped Page from the CurrentNavigationTask property of NavigationPage.

Potential PR was closed and not merged. https://github.com/xamarin/Xamarin.Forms/pull/625

Steps to Reproduce

Simple test case:
1) get start with Page1
2) navigate to Page2,
3) get back to Page1 with PopAsync() or back button.

Basic Information

• Version with issue: 1.4.3

Reproduction Link

PagePopMemory.zip

XamarinFormsBugs.zip

[emmielewis]

What version of Xamarin Forms is this fix in? We are on 3.0.0.482510 and we are still experiencing the issue.

[MaxFe]

We are on version 3.1.0.583944 and still have that problem when using BackButton (analysed with VisualStudio Profiler and UWP). Has anyone an idea why that is?

[ewoody]

I can reproduce this issue on iOS and Android with a simple sample in Xamarin.

[samhouts]

Reopening for further investigation. @emmielewis @MaxFe @ewoody, Does the sample project attached to this ticket still exhibit the issue for you? If not, can you please alter it such that it does, or attach your own sample project to help us see what we missed? Thanks!!

[MaxFe]

This example is not reproducing the memory leak. I tried to change it so that it will but was not successful in that 30 min. before work. I will try it this weekend.

[ewoody]

I did use Xamarin Profiler to monitor memory usage and I can see the page2 is still in memory.

In order to clarify our memory issues, I have modified the App.cs, see my code. I have used GC.Collect() in Page1. Appearing() and want to clear Page2 instance after it is popped. However, after I push page2 and then click back for 20 times, you can see the page2 has 20 instance in Xamarin Profiler and the app memory usage keeps growing.

Question - how to avoid growing memory usage when a navigation page keeps pushing and popping?

```c#
namespace XamarinFormsBugs
{
using System;
using System.Reflection;
using System.Threading.Tasks;

using Xamarin.Forms;

public class App : Application
{
    public App()
    {
        this.MainPage = new NavigationPage(new Page1());
    }
}

public class Page1 : ContentPage
{
    public Page1()
    {
        var stack = new StackLayout() { VerticalOptions = LayoutOptions.Center };

        stack.Children.Add(new Label() { VerticalOptions = LayoutOptions.Center, XAlign = TextAlignment.Center, Text = "Page 1" });
        stack.Children.Add(new Button() { Text = "Push Page2", Command = new Command(async () => await this.PushPage2()) });

        this.Content = stack;
    }

    private WeakReference page2Tracker;

    protected override async void OnAppearing()
    {
        base.OnAppearing();
        GC.Collect();
    }

    private async Task PushPage2()
    {
        var page2 = new Page2();
        await this.Navigation.PushAsync(page2);
    }
}

public class Page2 : ContentPage
{
    public Page2()
    {
        var stack = new StackLayout() { VerticalOptions = LayoutOptions.Center };
        stack.Children.Add(new Label() { VerticalOptions = LayoutOptions.Center, XAlign = TextAlignment.Center, Text = "Page 2" });
        this.Content = stack;
    }
}

}
`

[ewoody]

bwn, I have changed the xamarin lib to be

[ewoody]

<package id="Xamarin.Forms" version="3.1.0.697729" targetFramework="xamarinios10" />

[PureWeen]

I attached a sample to the original issue with what @ewoody posted using 3.2 pre 3

I only saw leaks Android related to the GestureManager

When I tested on UWP and iOS it looked like all resources were being collected properly

[ewoody]

Where could I get 3.2 pre 3 libs in order to verify your conclusion from my side?

[rmarinho]

they are up on Github and Nuget already

[ewoody]

No, iOS app, using 3.2 pre 3, after I push page2 and then click back for 13 times, you can see the page2 has 13 instances in Xamarin Profiler and the app memory usage keeps growing.

[PureWeen]

@ewoody can you attach the sample you're using for your tests?
Also you might be interpreting that 13 as 13 Page2's have been allocated but they aren't live. The profiler counts total allocations and just gives you a count of how many times that class has been allocated

In the allocations filter if you check "only live objects" do you still see page2? With the sample I uploaded I don't

Either way though I'll update the issue so once this is looked at iOS is rechecked during the fix

[salgiza]

Any news on this bug? Yesterday I posted a question in the Xamarin.Forms forum that might seem related to this: https://forums.xamarin.com/discussion/155697/possible-memory-leak-in-xamarin-forms

There is more info on the post but, the two main things to take from it:

• It can be reproduced running one of the project templates included in VS for macOS.
• I have a project where this only happens when I use toolbar items (what?).

[vravindranath]

Any update on this. The Xamarin forms 4plus version has also this issue. Even when the page disappears and it is removed from navigation stack the instances are active. This leads to memory crash in iOS. Looks like this bug is still open from last 2 years and there is no response. @samhouts. Any update??

[JKennedy24]

+1 on this.

It makes it very hard to start looking for memory leaks when NavigationPage is holding onto the page when it should be disposed

Also, this bug was originally posted 3 and a half years ago

[samhouts]

This issue doesn't seem to have had any activity in a long time. We're working on prioritizing issues and resolving them as quickly as we can. To help us get through the list, we would appreciate an update from you to let us know if this is still affecting you on the latest version of Xamarin.Forms, since it's possible that we may have resolved this as part of another related or duplicate issue. If we don't see any new activity on this issue in the next 30 days, we'll evaluate whether this issue should be closed. Thank you!

[samhouts]

Since we haven't heard from you in more than 30 days, we hope this issue is no longer affecting you. If it is, please reopen this issue and provide the requested information so that we can look into it further. Thank you!