Bug 48998 - Back on NavigationPage causes System.ObjectDisposedException
Summary: Back on NavigationPage causes System.ObjectDisposedException
Alias: None
Product: Forms
Classification: Xamarin
Component: Android ()
Version: 2.3.3
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2016-12-05 09:38 UTC by Michal Sima
Modified: 2017-10-18 22:27 UTC (History)
5 users (show)

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

test project (321.65 KB, application/x-zip-compressed)
2016-12-05 09:38 UTC, Michal Sima

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:

Description Michal Sima 2016-12-05 09:38:18 UTC
Created attachment 18769 [details]
test project

When I have NavigationPage and ContentPage with ListView application crashes after click on Back.   

Unhandled Exception:

System.ObjectDisposedException: Cannot access a disposed object.

Object name: 'Xamarin.Forms.Platform.Android.LabelRenderer'.

Problem is binding in listview items. Binding is still active even when I left page with listview. After click on Back button controls from listview items are not disposed but renderers are disposed. Of course it depends on garbage collector. When you are unlucky and GC has been called after Back and you try change binded data then application is going to crash.

You can try it with test project from attachment.

Just click about 4 times to GO TO LIST VIEW and then Back and application is going to raise exception.

I used there LabelEx because of breakpoint to binded property but the result is the same with Label. You can bind Text, IsVisible...result is going to be the same -- EXCEPTION.

Sample project changes IsVisible property.
Comment 1 Michal Sima 2016-12-05 15:51:16 UTC
Tested on device with Android 6.0 and emulator with Android 4.4
Comment 2 Jon Goldberger [MSFT] 2016-12-15 19:35:02 UTC
I opened the test project and could reproduce the issue, but I noted that you were calling GC.Collect in the Clicked handler for the "Go yo ListView" button. Removing that call to GC.Collect stopped the exception from happening. Generally you should not have to , or want to, call GC.Collect except in certain special circumstances. Is there a particular reason you were calling it?
Comment 3 Michal Sima 2016-12-15 21:46:49 UTC
Thanks a lot. The reason why I'm calling GC.Collect is that I need reproduce the bug on this small application which doesn't consume enough memory to call GC automatically. So GC.Collect is there to force a garbage collection. 

In our applications we don't call GC.Collect but they are much bigger so after some time of using GC is called automatically and after that applications crashes.

So yes when you remove GC.Collect it looks that application works but it's not the solution because GC can start whenever automatically when application will need more memory.
Comment 4 Jon Goldberger [MSFT] 2016-12-19 22:21:39 UTC
Thanks for the explanation. I will mark this as confirmed then. 

It seems the issue occurs on Android Only, but works on iOS. I noted that the call to PushAsync was not awaited, but fixing that made no difference. It seems that the LabelRenderer is disposed when the setter for the VisibleEx property of LabelEx is called and the line of code 

>IsVisible = _visible;

is run.
Comment 5 Rui Marinho 2017-08-15 18:24:00 UTC
Should be fixed on 2.4.0
Comment 6 Samantha Houts [MSFT] 2017-08-15 19:01:44 UTC
Comment 7 Rui Marinho 2017-10-18 22:27:57 UTC
Should be fixed on 2.4.0 service release 2