This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
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)

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


Attachments

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.

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