Bug 47577 - handle must valid, Parameter name: instance
Summary: handle must valid, Parameter name: instance
Status: RESOLVED DUPLICATE of bug 56902
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler (show other bugs)
Version: 7.0 (C8)
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Jonathan Pryor
URL:
Depends on:
Blocks:
 
Reported: 2016-11-21 14:29 UTC by contatti
Modified: 2017-07-17 09:38 UTC (History)
8 users (show)

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


Attachments
Android monitor log (6.08 KB, text/plain)
2016-11-21 14:29 UTC, contatti
Details

Description contatti 2016-11-21 14:29:18 UTC
Created attachment 18571 [details]
Android monitor log

Hi,

I use a JavaList<> as data for my RecyclerView. The app works normally, but from a recent update the app crash with this error:
Unhandled Exception:
System.ArgumentException: Handle must be valid.
Parameter name: instance

This happen when I use with the JavaList (method doesn't matter, can be Count, [], etc).
In Android Monitor i get this additional information:
 at Java.Interop.JniEnvironment+InstanceMethods.CallIntMethod (Java.Interop.JniObjectReference instance, Java.Interop.JniMethodInfo method) [0x0000d] in <a043032cf94a485190047a14918b9f60>:0 

I attach the entire log I got from Android Monitor
Comment 1 contatti 2016-11-23 09:08:25 UTC
Dude, it's a serious bug. I can confirm because now it happen in another app! Ask for detail, but fix it!
Comment 2 contatti 2016-11-23 12:12:12 UTC
I try to downgrade Xamarin to the last version of Cycle 7. It works.
The problem it happens only with version 8.
Comment 3 Jonathan Pryor 2016-11-23 16:44:36 UTC
@contatti: Xamarin.Android 7.0 ("Cycle 8") changed the default bridge from "old" to "tarjan". Please try using the "old" implementation:

https://developer.xamarin.com/guides/android/advanced_topics/garbage_collection/#GC_Bridge_Options

MONO_GC_PARAMS=bridge-implementation=old

If that fixes the issue, you found a GC bridge bug. (Yay?) If possible, please attach a test case so that our GC team can fix it.
Comment 4 contatti 2016-11-25 09:30:59 UTC
Hi,
I try your suggest and it works! 

I will create a test case on next monday, however I can tell you I use the object JavaList<> as data inside a Android.Support.V4.App.Fragment

Regards,
Comment 5 contatti 2016-11-28 12:00:23 UTC
I try to create a test case, but I am unable to reproduce the bug.

Maybe we can try with a full app?
Comment 6 Jonathan Pryor 2016-11-28 16:46:55 UTC
@contatti: If you can provide the full app and repro instructions, that would be fine.
Comment 7 Rodrigo Kumpera 2017-02-22 23:23:53 UTC
Hi,

Do we have an update on this?
Comment 8 contatti 2017-04-06 07:19:04 UTC
Hi,
It seems now fixed. Apologize me for lack of updates, but my job keep me very busy.

Regards,
Comment 9 contatti 2017-04-07 08:55:07 UTC
hi,

Unfortunately after an extensive test the problem still appear.
In these days I do not have much time, I try to recreate the problem in a sample with no success.
Comment 10 tmrog 2017-05-31 12:33:23 UTC
I am seeing a very similar thing so maybe this info will help.

I have a custom layout I am using with an adapter.  This layout and a ViewDragHelper and a GestureDetectorCompat as member variables that are created in OnFinishInflate().

While running the app and testing app bar action mode I get the below output in the application output that appears to be a GC run.  After than runs, the Java.Lang.Object of both of these classes have been disposed.  The debugger tells me that when I get the System.ArgumentException.  I am dead in the water once the GC runs.

[art] Starting a blocking GC Explicit
[art] Explicit concurrent mark sweep GC freed 8269(934KB) AllocSpace objects, 3(80KB) LOS objects, 40% free, 7MB/12MB, paused 545us total 33.815ms
[Mono] GC_TAR_BRIDGE bridges 948 objects 1387 opaque 526 colors 927 colors-bridged 914 colors-visible 914 xref 469 cache-hit 0 cache-semihit 0 cache-miss 13 setup 0.18ms tarjan 1.81ms scc-setup 0.41ms gather-xref 0.09ms xref-setup 0.02ms cleanup 0.22ms
[Mono] GC_BRIDGE: Complete, was running for 61.92ms
[Mono] GC_MINOR: (Nursery full) time 20.14ms, stw 21.13ms promoted 679K major size: 1536K in use: 858K los size: 2048K in use: 1695K
Comment 11 tmrog 2017-05-31 12:46:57 UTC
I just tested with "MONO_GC_PARAMS=bridge-implementation=old" environment variable set and cannot reproduce my issue.  Before I try to put together a test project to reproduce this issue, is this something that you need or is this issue understood?
Comment 12 Jonathan Pryor 2017-06-23 16:59:42 UTC
> is this something that you need or is this issue understood

Yes. Please oh please oh please yes, we would *love* to have a test project. We have not been able to create a repro, and haven't found any other sources for a repro.
Comment 13 Jonathan Pryor 2017-07-03 13:24:34 UTC
Marking as a duplicate of Bug #56902 as Bug #56902 contains a repro project (yay!) and expresses the same bug behaviors.

*** This bug has been marked as a duplicate of bug 56902 ***

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