Bug 38982 - NavigationPage rendering pages that aren't shown, will freeze the app (Material Design)
Summary: NavigationPage rendering pages that aren't shown, will freeze the app (Materi...
Status: RESOLVED NORESPONSE
Alias: None
Product: Forms
Classification: Xamarin
Component: Android ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Paul DiPietro [MSFT]
URL:
Depends on:
Blocks:
 
Reported: 2016-02-22 10:55 UTC by Ronald
Modified: 2017-06-15 16:23 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:
Status:
RESOLVED NORESPONSE

Description Ronald 2016-02-22 10:55:14 UTC
Using: Forms, TabbedPage, NavigationPage (also Material Design package, but not needed), XAML, data binding

Effect: All pages added to the NavigationPage seem to be rendered and freezes the application. With Material Design package this will eventual crash the application (a crash has also occurred without Material Design, but it's more difficult).

Reproduce:
- Create 3 Tabs
- In Tab 1 add a NavigationPage
- Navigate some levels deep into the NavigationPage
- Go to Tab 2
- Go to Tab 3
- Go to Tab 2
- Go to Tab 1 (slow down)
- Do the "Go to Tabs" a few times. It will freeze the app and might crash.

(You might want to add Debug.WriteLines in the OnAppearing overrides of the pages)

Tested on: Samsung S3

Attached a sample app.


Part of the Application Output:
[Mono] [0x68dead18] worker starting
[Mono] [0x5cbcf558] hill climbing, change max number of threads 4
[AbsListView] unregisterIRListener() is called 
[Mono] GC_BRIDGE waiting for bridge processing to finish
[Mono] GC_OLD_BRIDGE num-objects 5686 num_hash_entries 15304 sccs size 10466 init 0.00ms df1 28.73ms sort 6.63ms dfs2 22.36ms setup-cb 2.99ms free-data 17.77ms links 17793/17793/179308/46 dfs passes 38783/28259
[Mono] GC_MINOR: (Nursery full) pause 71.23ms, total 72.28ms, bridge 0.00ms promoted 5056K major 5056K los 824K
[Mono] [0x5cbcf558] hill climbing, change max number of threads 6
[Mono] [0x5c98ba18] hill climbing, change max number of threads 12
[AbsListView] unregisterIRListener() is called 
[Mono] [0x5b5d09a8] hill climbing, change max number of threads 4
[Mono] [0x5c98bc80] hill climbing, change max number of threads 5
[Mono] [0x68deaad0] hill climbing, change max number of threads 16
Thread started: <Thread Pool> #19
Thread started: <Thread Pool> #20
[Mono] [0x6b15b5c0] worker starting
Thread started: <Thread Pool> #21
Thread started: <Thread Pool> #22
[Mono] [0x6b035d10] worker starting
[Mono] [0x6b01fd48] worker starting
[Mono] [0x6b0bb948] worker starting
[Mono] [0x5cbcf558] hill climbing, change max number of threads 5
[Mono] [0x6afed3b8] hill climbing, change max number of threads 18
Thread started: <Thread Pool> #23
[Mono] [0x653fe160] worker starting
Thread started: <Thread Pool> #24
[Mono] [0x5cd76200] worker starting
[Mono] [0x6b013c58] hill climbing, change max number of threads 17
[Mono] [0x5cc28060] hill climbing, change max number of threads 4
[Mono] [0x5cbcf558] hill climbing, change max number of threads 5
[Mono] [0x5cd76200] hill climbing, change max number of threads 18
[Mono] [0x6b0bb948] hill climbing, change max number of threads 5
[Mono] [0x5cbcf558] hill climbing, change max number of threads 18
[Mono] [0x6afeda48] hill climbing, change max number of threads 4
[Mono] [0x6b013c58] hill climbing, change max number of threads 12
[Mono] [0x5b5d09a8] hill climbing, change max number of threads 15
[Mono] [0x68deaad0] hill climbing, change max number of threads 4
[Mono] [0x5c98bc80] hill climbing, change max number of threads 5
[Mono] [0x5cd76200] hill climbing, change max number of threads 9
[Mono] [0x6afed3b8] hill climbing, change max number of threads 4
[Choreographer] Skipped 827 frames!  The application may be doing too much work on its main thread.
Thread finished: <Thread Pool> #16
[Mono] [0x68dead18] worker finishing
Thread finished: <Thread Pool> #18
[Mono] [0x68e0c880] worker finishing
Comment 1 Ronald 2016-02-22 11:25:48 UTC
As I couldn't attach the zip file.

Here is a repo with the code:
https://github.com/RonaldV/xamarin-android-navigationpage-test
Comment 2 Michael Rumpler 2016-04-20 21:32:02 UTC
I have a similar problem and I already added all my info to bug #38577 as this displays the same symptoms, but it seems to be caused by the Xamarin Inspector. I encountered the bug the first time on 2016-03-15 after I installed the Inspector, but I uninstalled it afterwards and the bug remained.

Here is some info about my app:

It is a Xamarin.Forms app with AppCompat which first shows a NavigationPage with just one ContentPage. On app start it starts loading all previously opened files in a background thread. As soon as all files are reloaded, it sets the MainPage to a new MasterDetailPage (Split) with both Master and Detail being NavigationPages. When the app hangs, then the tablet only shows the navigation area of that UI. I.e. Titles and ToolbarItems are there, but the rest of the Master and Detail pages are empty.
The app writes "UI.RefreshMainPage[174]: done" to the log when its background work is finished and the UI should have been refreshed. In https://bugzilla.xamarin.com/attachment.cgi?id=15779 that was at 14:38:15.517. I gave it until 14:45:26.095, but it never came back.

For five weeks my app almost always hung when I started it. It hung for at least 30secs, avg. 2mins and sometimes it didn't come back at all.

On 2016-04-13 I wanted to install a new XamarinVS version, but the installation failed. I cancelled it, rebooted and then Xamarin was not visible in VS anymore. So I installed VS 2015 update 2. This installed XamarinVS 4.0.3.214 and my problems were gone. The app behaved as it should.

Today I installed XamarinVS 4.1.0.313 and the app hung again. I switched back from the alpha channel (where I've been for a year or so) to stable which installed 4.0.3.214 and the problem seems to be gone. So I'm now pretty sure that it is something in XamarinVS 4.1.

Some more info can be found in the attachments to bug #38577:

https://bugzilla.xamarin.com/attachment.cgi?id=15778
The XamarinVS logs from the last week. On 2016-04-13 it did not work, from the 14th to 19th it worked and on the 20th it didn't work anymore.

https://bugzilla.xamarin.com/attachment.cgi?id=15779
The text from the output window when the app hang. This includes many of the messages Ronald also posted here and also many GC messages. I guess they come, because so many threads are started/finish and then must be GCed.
Comment 3 Paul DiPietro [MSFT] 2017-03-26 23:20:47 UTC
Are you still experiencing this issue on the latest stable/prerelease, and if so, is this generally only on the S3 or perhaps on older devices in general? If so, this might require testing against the same device or a device of similar age as the emulator generally seems smooth.
Comment 4 Paul DiPietro [MSFT] 2017-06-15 16:23:51 UTC
Closing this due to no response. Please reopen and attach a minimized reproduction project if the issue still exists as of the latest prerelease or nightly build.