Bug 39654 - JNI ERROR (app bug): accessed deleted global reference 0xDEADD00D
Summary: JNI ERROR (app bug): accessed deleted global reference 0xDEADD00D
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler ()
Version: 6.0.1 (C6SR1)
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Jonathan Pryor
Depends on:
Reported: 2016-03-15 16:15 UTC by Stefan Reinhard
Modified: 2017-08-23 20:35 UTC (History)
5 users (show)

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

adb_logs.zip (25.64 KB, application/zip)
2016-03-15 16:15 UTC, Stefan Reinhard
Error case without GREF logging (1.56 MB, video/mp4)
2016-03-16 16:29 UTC, Stefan Reinhard
App launch with GREF logging enabled (6.92 MB, video/mp4)
2016-03-16 16:39 UTC, Stefan Reinhard

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:

Description Stefan Reinhard 2016-03-15 16:15:37 UTC
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 ===

Version: 0.32.0
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Apple Developer Tools ===

Xcode 7.2.1 (9548.1)
Build 7C1002

=== Xamarin.iOS ===

Version: (Business Edition)
Hash: 58ba2bc
Branch: master
Build date: 2016-03-03 09:05:19-0500

=== Xamarin.Android ===

Version: (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 ===

Version: 0.6.5
Location: /Applications/Xamarin Android Player.app

=== Xamarin.Mac ===

Version: (Starter Edition)

=== Xamarin Inspector ===

Hash: 45b35bb
Branch: master
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
    root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
Comment 1 Stefan Reinhard 2016-03-16 13:31:51 UTC
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.
Comment 2 Jonathan Pryor 2016-03-16 13:54:18 UTC
> 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* [0], 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.

[0]: I really should get some metrics? Maybe?
Comment 3 Stefan Reinhard 2016-03-16 16:29:12 UTC
Created attachment 15432 [details]
Error case without GREF logging
Comment 4 Stefan Reinhard 2016-03-16 16:39:39 UTC
Created attachment 15433 [details]
App launch with GREF logging enabled
Comment 5 Jonathan Pryor 2016-03-16 16:55:38 UTC
@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...
Comment 6 Stefan Reinhard 2016-03-16 17:04:28 UTC
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?
Comment 7 Stefan Reinhard 2016-03-16 17:16:38 UTC
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...
Comment 8 apujadas 2016-06-09 19:13:31 UTC
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?
Comment 9 Prashant [MSFT] 2017-06-29 06:53:08 UTC
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.
Comment 10 Cody Beyer (MSFT) 2017-08-23 20:35:53 UTC
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!