Bug 35471 - JavaCast<T>() doesn't properly handle for ACW types.
Summary: JavaCast<T>() doesn't properly handle for ACW types.
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler (show other bugs)
Version: 4.20.0
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Jonathan Pryor
Depends on:
Reported: 2015-11-02 16:06 UTC by Jonathan Pryor
Modified: 2016-02-23 02:57 UTC (History)
6 users (show)

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


Description Jonathan Pryor 2015-11-02 16:06:49 UTC
Via Bug #33767.

Imagine, if you will, a .axml file which specifies one type:

    <TextView android:id="myTextView"/>

Then C# code which uses a different type, a *managed subclass* (not a binding!):

    class MyTextView : TextView { /* ... */ }

Then we lookup the view:

    var text = FindViewById<MyTextView>(Resource.Id.myTextView);

Expected results: It should blow up, because the myTextView id ISA TextView, NOT a MyTextView.

Actual results: It doesn't blow up. Instead, we get a MyTextView wrapper (alias) around the "real" MyTextView type.

GREF logging gives a head-scratching line like:

> handle 0x1015a6; key_handle 0x218fe05: Java Type: `android/widget/TextView`; MCW type: `Example.MyTextView`

Theoretical follow-on effects: GC SIGSEGVs as objects are "lost" because there's no Java-side peer instance to hold them for bridge GC operations (the monodroidAddRef()/etc. methods).
Comment 1 Ludovic Henry 2015-11-02 16:18:37 UTC
*** Bug 33767 has been marked as a duplicate of this bug. ***
Comment 2 Jonathan Pryor 2015-12-15 20:33:16 UTC
Fixed in monodroid/363ab63e.
Comment 3 williamd 2015-12-17 21:54:23 UTC
Any idea when this fix will be available in the Alpha channel?
Comment 4 Jonathan Pryor 2015-12-17 22:23:57 UTC
> Any idea when this fix will be available in the Alpha channel?

Next year some time.

This fix is currently slated for Cycle 7, which has no firm branch point (just an ideal wish...). We could plausibly add it to Cycle 6 SR2, but we don't currently know if we'll even *have* a C6SR2, and most of the company is going on vacation for the holidays (*I* certainly am...), so...
Comment 5 williamd 2015-12-18 13:22:09 UTC
Thanks for the update Jonathan, I appreciate it. I'll keep my eyes peeled when Cycle 7 rolls around sometime next year (or Cycle 6 R2 if that ends up being a release).
Comment 6 alex 2016-01-08 20:39:24 UTC
Is there any workaround until fix makes into Stable channel?

Thank you!
Comment 7 Chase Florell 2016-01-15 23:33:11 UTC
Also interested in this fix. Crashes only when Debugger is connected... crashing on OkHttp (and I am using ModernHttpClient - not sure if that makes a difference).
Comment 8 Jonathan Pryor 2016-01-16 03:27:47 UTC
> Is there any workaround until fix makes into Stable channel?

The "workaround" is to ensure that your types match. The crash is because the type specified in e.g. main.axml doesn't match the type used with FindViewById<T>().

(Which is a terrible answer. Perhaps "no" is the actual answer.)

> Crashes only when Debugger is connected... crashing on OkHttp (and I am using 
> ModernHttpClient - not sure if that makes a difference)

That sounds like it might be a different bug, because I don't see why OkHttp or ModernHttpClient would result in the type mismatch described in Comment #0.
Comment 9 williamd 2016-01-18 14:13:54 UTC
So you're saying that bug 33767 (which deals with OkHttp/ModernHttpClient) sounds like a different bug, correct? Should it be marked as a Resolved Duplicate of this bug then? Or are there two separate bugs in 33767?
Comment 10 Jonathan Pryor 2016-01-18 15:59:05 UTC
In bug #33767, OkHttp was *present*, but upon further analysis OkHttp didn't seem to be *involved* in the actual crash. The *cause* of the crash was the mismatch between Java runtime type and Android Callable Wrapper type (Bug #35571).

I am not aware of any bugs between OkHttp/ModernHttpClient and the GC.

Crashes when the debugger is connected sounds like it could be Bug #35739, which is an ART-related abort because something hasn't been initialized.

Notice (2018-05-21): bugzilla.xamarin.com will be switching to read-only mode on Thursday, 2018-05-25 22:00 UTC.

Please join us on Visual Studio Developer Community and GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs and copy them to the new locations as needed for follow-up. The See Also field on each Bugzilla bug will be updated with a link to its new location when applicable.

After Bugzilla is read-only, if you have new information to add for a bug that does not yet have a matching issue on Developer Community or GitHub, you can create a follow-up issue in the new location. Copy and paste the title and description from this bug, and then add your new details. You can get a pre-formatted version of the title and description here:

In special cases you might also want the comments:

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.

Note You need to log in before you can comment on or make changes to this bug.