Bug 35471 - JavaCast<T>() doesn't properly handle for ACW types.
Summary: JavaCast<T>() doesn't properly handle for ACW types.
Status: RESOLVED FIXED
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
URL:
Depends on:
Blocks:
 
Reported: 2015-11-02 16:06 UTC by Jonathan Pryor
Modified: 2016-02-23 02:57 UTC (History)
6 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 FIXED

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.