Skip to content
This repository has been archived by the owner on May 1, 2024. It is now read-only.

[Bug] Is XF Shell navigation leaking memory? #14657

Closed
danielkraut opened this issue Sep 24, 2021 · 1 comment
Closed

[Bug] Is XF Shell navigation leaking memory? #14657

danielkraut opened this issue Sep 24, 2021 · 1 comment
Labels
a/performance a/shell 🐚 i/high Completely doesn't work, crashes, or is unusably slow, has no obvious workaround; occurs less often t/bug 🐛

Comments

@danielkraut
Copy link
Contributor

Description

Every time app adds a page to navigation stack via Shell.Current.GoToAsync("MyPage") a new instance is created, which is to be expected. But after navigating back (either with Shell.Current.GoToAsync("..") or with back button) that page is never released from memory or at least is seems that it is the case. I have tried to check it with a finalizer but it is never called, which may be an implementation detail but having also some private object created then its finalizer is also never called and that seems like a bug. I also tried to use Xamarin Profiler which also shows that alive objects are only growing.

When using the older navigation style - PushAsync, PopAsync - finalizers are called properly. I will attach a minimal example app to demonstrate the issue which is just the project autogenerated by Visual Studio stripped down to just 2 pages.

If this behavior is expected I would like to get a clarification how XF.Shell manages memory. Right now I am dealing with my own application which after some time only increases its memory usage and never releases it and I am wondering if XF.Shell may be responsible for that. This same issue have already been discussed here #11476 but I don't think it was resolved in any way as the responders focused on Messagin centre but I am not using that.

Steps to Reproduce

  1. Create Xamarin Forms Shell application
  2. Create 2 pages - one home page and the other registered with Routing.RegisterRoute
  3. Add button to navigate from main page to other page and back
  4. Add private field to other page which contain object of some custom class
  5. Add finalizer to other page and custom class, put breakpoint or writing to console to the finalizer
  6. Navigate back nad forth between main page and other page
  7. Observer that finalizers are never called

Expected Behavior

Allocated data is released when a page is removed from navigation stack.

Actual Behavior

Finalizer of the removed page or finalizer of any object the page has reference to is never called.

Basic Information

  • Version with issue: 5.0.0-sr3, 5.0.0-sr4
  • Last known good version: unknown
  • Platform Target Frameworks:
    • Android: 10, 11 (haven't tried other OS/platforms)
  • NuGet Packages: none
  • Affected Devices: all

Environment

Visual Studio: Visual Studio 2019 16.9.3, 16.11.2

Screenshots

obrazek

Reproduction Link

Minimal example:
ShellMemoryLeak.zip

@danielkraut danielkraut added s/unverified New report that has yet to be verified t/bug 🐛 labels Sep 24, 2021
@jsuarezruiz jsuarezruiz removed the s/unverified New report that has yet to be verified label Oct 1, 2021
@jsuarezruiz jsuarezruiz added the i/high Completely doesn't work, crashes, or is unusably slow, has no obvious workaround; occurs less often label Oct 1, 2021
jfversluis pushed a commit that referenced this issue Jan 7, 2022
* Create test to prove that navigated-from content pages are not garbage collected when using Shell

issue #14657

* Fix disposing Shell objects

removing drawer listener (_drawerToggle) allows shell pages to be collected by GC

issue #14657

* Correctly dispose views

Shell TitleView is explicitly set to null, because otherwise pages would not be disposed of. Also views are explicitly removed during disposal.

issue #14657
@jfversluis
Copy link
Member

This can be closed for now: #14717 (comment)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
a/performance a/shell 🐚 i/high Completely doesn't work, crashes, or is unusably slow, has no obvious workaround; occurs less often t/bug 🐛
Projects
None yet
Development

No branches or pull requests

3 participants