Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
Created attachment 15409 [details]
Our app crashes infrequently with the following error:
JNI ERROR (app bug): accessed deleted global reference 0x(memory address)
The crash isn't directly reproducible, however, we have at least one scenario in which it can be triggered quite reliably.
I've attached some adb logs from different devices showing always the same error.
Our (blindfolded) working theory is this: When garbage collection kicks in in Xamarin.Android and Android simultaneously and then bad stuff happens. This might be totally incorrect and is a naive guess at best.
I tried all the following things (and a few more) to overcome this error without any luck:
- Switching to different GC bridges (old, new and tarjan)
- Disabling the few GC.Collect(0) calls we have in our code
- Profile the app and make sure no memory leak is involved
- Use different Android target SDKs
- Avoid using Bitmap's in our repro case
- Avoid Typeface.Create() due to https://bugzilla.xamarin.com/show_bug.cgi?id=25443
- Reproducing the error with GREF logging. Unfortunately I could not reproduce the error this way (Also, the app is reeeally slow).
I don't really have any further ideas where to look into. So I though it might be a good idea to start blaming you guys ;-)
Could this be a bug in Xamarin.Android?
*** Xamarin Version dump ***
=== Xamarin Studio ===
Version 5.10.3 (build 26)
Installation UUID: 420ea299-b1f7-4000-a53d-e84cc67fd449
Mono 4.2.3 (explicit/832de4b)
GTK+ 2.24.23 (Raleigh theme)
Package version: 402030004
=== Xamarin.Profiler ===
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler
=== Apple Developer Tools ===
Xcode 7.2.1 (9548.1)
=== Xamarin.iOS ===
Version: 22.214.171.124 (Business Edition)
Build date: 2016-03-03 09:05:19-0500
=== Xamarin.Android ===
Version: 126.96.36.199 (Business Edition)
Android SDK: /Users/sr/Library/Developer/Xamarin/android-sdk-macosx
Supported Android versions:
2.3 (API level 10)
4.0.3 (API level 15)
4.2 (API level 17)
4.4 (API level 19)
5.0 (API level 21)
5.1 (API level 22)
6.0 (API level 23)
SDK Tools Version: 25.0.10
SDK Platform Tools Version: 24.0.0 rc1
SDK Build Tools Version: 23.0.2
Java SDK: /usr
java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
Android Designer EPL code available here:
=== Xamarin Android Player ===
Location: /Applications/Xamarin Android Player.app
=== Xamarin.Mac ===
Version: 188.8.131.52 (Starter Edition)
=== Xamarin Inspector ===
Build date: Thu Jan 14 18:53:32 UTC 2016
=== Build Information ===
Release ID: 510030026
Git revision: ac9b7fcba9ee92ac30c8eb90f20c2228ce033efa
Build date: 2016-03-01 18:02:09-05
Xamarin addins: 633fde3bf405e3c402a51980976c431c204cf4f6
Build lane: monodevelop-lion-cycle6-c6sr2
=== Operating System ===
Mac OS X 10.11.3
Darwin stefans-macbook-pro.home 15.3.0 Darwin Kernel Version 15.3.0
Thu Dec 10 18:40:58 PST 2015
Just out of curiosity I switched over to Alpha channel since the Release Notes of Xamarin.Android 6.1 sounds very exciting (good job guys!). Unfortunately, I could reproduce the very same error in that version too. Still no luck reproducing the error with GREF logging turned on.
> Reproducing the error with GREF logging. Unfortunately I could not reproduce the error this way.
That's sad, as that's usually the best way to determine where the GREF was invalidated...
> (Also, the app is reeeally slow)
How are you enabling GREF logging? *Usually* , GREF logging isn't that noticeable (to me!). LREF logging is *the pits*, and *immediately* noticeable.
How did you enable the logging? GREF only?
> adb shell setprop debug.mono.log gref
You could also try "truncated" GREF logging:
> adb shell setprop debug.mono.log gref-
Note the trailing `-`. The difference between `gref` and `gref-` is that the former *also* creates a grefs.txt file which contains full stack traces of where the GREF was created/destroyed, while `gref-` *doesn't*; it only prints creation and destruction messages to `adb logcat`, with no stack trace information.
: I really should get some metrics? Maybe?
Created attachment 15432 [details]
Error case without GREF logging
Created attachment 15433 [details]
App launch with GREF logging enabled
@Stefan: Thank you for the videos, but in Comment #2 I was wondering what specific command you were using to enable GREF logging. Attachment #15433 [details] is *very slow* (as you noted), so I'm thinking that either LREF logging has been enabled as well, or you're somehow creating *lots* of object references and GREFs...
Unfortunately, using the truncated GREF logging doesn't make the app execution really any faster.
I've uploaded two videos to demonstrate the effect when i activate GREF logging.
The one without GREF logging shows how the error can be reproduced in our App and is therefore actually kinda useful.
The second one shows the effect when I activate GREF logging (truncated version) and how the app is getting slow. This one is probably the most boring screencast recorded ever, don't watch it entirely or you'll lose ten minutes of your life you'll never get back ;-).
Probably I should have mentioned this before: Our app is using Xamarin.Forms and a lot of custom renderers.
When I activate GREF logging with other non trivial Xamarin.Forms apps I get the same result. Take the Xamarin Sports demo app for example: Without GREF logging starting the app and joining a league takes less than 20 seconds. With GREF logging enabled you end app at something south of 5 minutes.
Any idea how to dodge this?
You've commented even faster than me after uploading those videos ;-)
LREF logging is definetly not activate, I don't see any lrefc messages in adb logcat.
However, you are right about creating a lot of objects. When the first screen has been loaded, we end up at a GREF count of about 500. After finally navigating to the point where we can reproduce the error we stand at about 650 GREFs.
Our app is quite complex, we've been working over a year on the project now...
I'm facing the same issue here.
Made a post http://forums.xamarin.com/discussion/68558/app-random-crash-jni-error-app-bug-accessed-deleted-global-reference#latest where i provide a deeper context of whats going on in our app.
Any further help or update?
Thank you for taking the time to submit the bug. We are unable to reproduce this issue. Please attach a reproduction to the bug by starting with a clean Xamarin.Android project and adding just the code necessary to demonstrate the issue.
Because we have not received a reply to our request for more information we are closing this issue. If you are still encountering this issue, please reopen the ticket with the requested information. Thanks!