Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
NavigationPage leads to memory leaks from pages never being released, even after PopAsync.
**Steps to Reproduce**:
1. Run the attached project in VS to an iOS Simulator.
2. That will install the app on the simulator and confirm that it's deployed.
3. Stop debugging.
4. Open the Xamarin Profiler from the Analyze menu
5. Choose the Allocations template
6. Start recording
7. Filter allocations on "Test". This will show only instances of the Test classes in the sample (they are ContentPages)
8. Press the Go to Page 1 button to PushAsync a new page
9. Press the Go Back button to PopAsync
Continue this process and note the allocation count increasing.
Test2 instances keep increasing, despite them being popped.
Test2 should not keep increasing.
**Build Date & Platform**:
It was explained that Pages would remain in memory, even after PopAsync, for the duration of the NavigationPage. To test that, you can press the Reset Main Page button which does:
App.Current.MainPage = new NavigationPage(new Test1());
Even after this is done, allocations for Test1 increase and none of the Test2 allocations are freed.
The attached screenshot shows my attempts at reproducing this buy following the information here. Note* Allocations increased up to 13 before I stopped testing. It seems nothing was ever freed.
I also noticed that Memory Allocation was increasing with the count increases. I thought maybe the profiler was just showing a total and not a working set, but the memory never dropped either so that does not seem to be the case.
*** This bug has been marked as a duplicate of bug 45790 ***