Bug 57789 - ObjectDisposedException in Xamarin.Forms.Platform.Android.ButtonDrawable
Summary: ObjectDisposedException in Xamarin.Forms.Platform.Android.ButtonDrawable
Status: RESOLVED NORESPONSE
Alias: None
Product: Forms
Classification: Xamarin
Component: Android (show other bugs)
Version: 2.3.5
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2017-06-27 13:04 UTC by Matthew Richardson
Modified: 2017-09-21 16:06 UTC (History)
7 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 Matthew Richardson 2017-06-27 13:04:37 UTC
Object name: 'Android.Graphics.Bitmap'
System.ObjectDisposedException: Cannot access a disposed object.

Stack Trace
* at Java.Interop.JniPeerMembers.AssertSelf (Java.Interop.IJavaPeerable self):0 
* at Java.Interop.JniPeerMembers+JniInstanceMethods.InvokeNonvirtualInt32Method (System.String encodedMember, Java.Interop.IJavaPeerable self, Java.Interop.JniArgumentValue parameters):0 
* at Android.Graphics.Bitmap.get_Height () [0x0000a] in :0 
* at Xamarin.Forms.Platform.Android.ButtonDrawable.Draw (Android.Graphics.Canvas canvas) [0x00017] in :0
* at Android.Graphics.Drawables.Drawable.n_Draw_Landroid_graphics_Canvas_ (System.IntPtr jnienv, System.IntPtr native__this, System.IntPtr native_canvas) [0x0000f] in :0 
* at (wrapper dynamic-method) System.Object:24dc4af5-ef3d-4949-9eec-ffec8011afc6 (intptr,intptr,intptr)6 (intptr,intptr,intptr)

2.3.6-nightly   BAD
2.3.5-pre5      BAD
2.3.4.247       GOOD

Note, repro project to follow. Issue found in a production app during XF 2.3.5 upgrade testing.
The app is working perfectly under XF 2.3.4.247.
Comment 1 Rui Marinho 2017-06-27 18:05:38 UTC
Hi is it possible to send us a reproducion? 

Thanks
Comment 2 Matthew Richardson 2017-06-28 08:16:01 UTC
Hi Rui.

Further testing shows this is a regression from 2.3.5-pre3 to 2.3.5-pre5.
Unable to repro the problem with 2.3.5-pre3.

Working on a reproduction project this morning.

2.3.5-pre5      BAD
2.3.5-pre3      GOOD

Rui, I believe it may be related to one of the following PRs:
- [Android] Fix border on android buttons #941
- [Android] Dispose check before setting properties on Button #1013

My guess is likely it may be related to #941. Prior to introduction of ButtonBackgroundTracker, the crash did not occur. Has this class been sufficiently hardened against ObjectDisposedException?

Thanks
Matthew
Comment 3 Matthew Richardson 2017-06-29 17:20:39 UTC
Rui/Jason.

Have been working on this one all day. Couldn't repro it with a simple demo project, so have been building up the complexity to recreate the environment of our production app.

I think this may be a compound problem. We have a custom collection view built around RecyclerView on Droid which we have been using since XF 2.3.0-2.3.4. When this broke in pre5 I assumed it was a regression, but further testing seems to demonstrate that layout is being called on 'recycled' view containers after the elements have been disposed.

The previous renderer design prior to pre5 seemed to be more tolerant of this, but from PR #941 forward in pre5 this broke.

Looking at pre5/6 fast ButtonRenderer.cs, I would still like to suggest a PR to fix a potential NRE and tighten a couple of areas. But I am confident that we don't have a fundamental issue at this stage with the renderer itself.

Please keep this ticket open for now in case I find anything to the contrary tomorrow, but fairly confident at this stage that this it.

Thanks!
Comment 4 Matthew Richardson 2017-07-03 15:00:38 UTC
See related crash https://bugzilla.xamarin.com/show_bug.cgi?id=57910, but in progress bar renderer.
Comment 5 Matthew Richardson 2017-07-06 10:36:54 UTC
FYI - Tested this morning with a custom XF build based on XF 2.3.5-pre6 with #1031 [Android] Prevent ObjectDisposed exceptions on Fast Renderers applied.

Although we believe #1033 will resolve a number of the other ObjectDisposedExceptions, we can confirm it does not resolve this crash. We have seen this crash occur elsewhere too when we are not using RecyclerView, so it an investigation may still be required.

As with all of the ObjectDisposedExceptions, it is difficult to repro but we believe it is worth examining the new "ButtonDrawable.cs" class to ensure it is properly handling the dispose lifecycle.
Comment 6 Matthew Richardson 2017-07-06 13:44:00 UTC
Further testing points to object disposal not being handled correctly in the new "ButtonBackgroundTracker.cs" class introduced in PR #941.

We did a quick test using a custom build of XF 2.3.5-pre6 with the UpdateDrawable() method commented out in this class and we no longer received the exception in Android.ButtonDrawable.

I will do some further research into the exact root cause and report back later today.
Comment 7 Matthew Richardson 2017-07-07 10:32:19 UTC
[Android] Prevent ObjectDisposedException in ButtonBackgroundTracker
https://github.com/xamarin/Xamarin.Forms/pull/1040
Comment 8 Matthew Richardson 2017-07-25 07:27:17 UTC
[Android] Prevent ObjectDisposedException in ButtonBackgroundTracker
https://github.com/xamarin/Xamarin.Forms/pull/1066
Comment 9 Jimmy [MSFT] 2017-07-25 19:48:17 UTC
Setting as in-progress due to open pull request
Comment 10 Jimmy [MSFT] 2017-08-16 23:51:06 UTC
Hi Matthew, could you send over a repro project for this as mentioned in the pull request? You can send it to my email listed on here. Thanks!
Comment 11 Paul DiPietro [MSFT] 2017-09-21 16:06:44 UTC
Due to a lack of response for over a month we are closing this ticket. Please reopen with a proper reproduction if this is still occurring as of 2.4.0-pre3 and refer to the comment(s) on the closed PR. Thanks!