This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 35739 - Debugger exits with art/runtime/fault_handler.cc:117] Check failed: !initialized_
Summary: Debugger exits with art/runtime/fault_handler.cc:117] Check failed: !initiali...
Status: VERIFIED FIXED
Alias: None
Product: Android
Classification: Xamarin
Component: Debugger (show other bugs)
Version: 6.0.99
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Marek Habersack
URL:
: 35798 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-11-10 11:22 UTC by Przemysław Raciborski
Modified: 2016-06-15 02:30 UTC (History)
34 users (show)

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


Attachments
logcat (66.03 KB, image/png)
2015-11-10 12:26 UTC, Przemysław Raciborski
Details
IDE log (17.27 KB, text/plain)
2015-11-30 21:55 UTC, Pete Schmitz
Details

Description Przemysław Raciborski 2015-11-10 11:22:38 UTC
I get this information only when debug shared runtime + fast assembly is DISABLED.

RC1, debugger exists randomly - can't reproduce sample.
Comment 1 Przemysław Raciborski 2015-11-10 12:26:04 UTC
Created attachment 13760 [details]
logcat
Comment 2 Al Clark [MSFT] 2015-11-22 14:54:49 UTC
Hi Przemysław,

Thank you for your report.  Could you please try updating to the latest stable
and let me know if you still have an issue?  It's possible that this may
already have been addressed.  If so then I'd be obliged if you could include
the following:

1. Your full version information:

Xamarin Studio in Windows
"Help -> About -> Show Details -> Copy Information [button]"

Visual Studio
"Help -> About Microsoft Visual Studio -> Copy Info [button]"

Xamarin Studio in OS X
"Xamarin Studio -> About Xamarin Studio -> Show Details -> Copy Information
[button]"

2. Your IDE logs:

In Visual Studio:
Help -> Xamarin -> Zip Logs

Xamarin for Mac logs:
You can select the "Go -> Go to Folder" menu item in Finder, and then copy and
paste the path into the dialog.

~/Library/Logs/XamarinStudio-5.0

This folder can also be opened via "Help -> Open Log Directory".

Kind regards
Alan
Comment 3 Przemysław Raciborski 2015-11-22 17:47:22 UTC
The problem exists in stable branch too.
I will provide more information with IDE log tomorrow - I am pretty sure this bug will "show up" during my work.
Comment 4 Pete Schmitz 2015-11-30 21:55:21 UTC
Created attachment 14045 [details]
IDE log

This bug makes it difficult to test on phones with api 23+. I'd say the frequency is around ~66% of the time I attempt to debug my Forms application on a Nexus 6.

Attached is my IDE log, the art error occurs at the end, 1:25PM.

Version information:

=== Xamarin Studio ===

Version 5.10 (build 871)
Installation UUID: cdf96680-8350-445d-8a66-e5c2fdde0cdd
Runtime:
	Mono 4.2.1 (explicit/6dd2d0d)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 402010102

=== Xamarin.Profiler ===

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

=== Xamarin.Android ===

Version: 6.0.0.34 (Indie Edition)
Android SDK: /Users/pete/Library/Android/sdk/
	Supported Android versions:
		2.3    (API level 10)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.4    (API level 19)
		4.4.87 (API level 20)
		5.0    (API level 21)
		5.1    (API level 22)
		6.0    (API level 23)

SDK Tools Version: 24.4.1
SDK Platform Tools Version: 23.0.1
SDK Build Tools Version: 23.0.2

Java SDK: /usr
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)

=== Xamarin Android Player ===

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

=== Apple Developer Tools ===

Xcode 7.1 (9079)
Build 7B91b

=== Xamarin.Mac ===

Version: 2.4.0.109 (Starter Edition)

=== Xamarin.iOS ===

Version: 9.2.1.51 (Indie Edition)
Hash: 3c0ec35
Branch: master
Build date: 2015-11-12 13:05:39-0500

=== Build Information ===

Release ID: 510000871
Git revision: 4e9c5abb5ffdae12ba02ac49da83f8b2011dbb88
Build date: 2015-11-12 06:02:54-05
Xamarin addins: 55007ed0e56436f385d8e26394a45be563abc7e8
Build lane: monodevelop-lion-cycle6

=== Operating System ===

Mac OS X 10.11.1
Darwin Peters-MacBook-Pro.local 15.0.0 Darwin Kernel Version 15.0.0
    Sat Sep 19 15:53:46 PDT 2015
    root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64



Excerpt from the android tools log:


[2015-11-30 13:25:10.5] DEBUG: NotifyPhase: Upload completed
[2015-11-30 13:25:10.6] DEBUG: KillProcessIfRunningAndWaitForExit: Checking whether app iSurvey.Android is running
[2015-11-30 13:25:10.6] DEBUG: RunShellCommand: -SERIAL- ps
[2015-11-30 13:25:10.8] DEBUG: KillProcessIfRunningAndWaitForExit: App was not running, skipping kill
[2015-11-30 13:25:10.8] DEBUG: RunShellCommand: -SERIAL- date +%s
[2015-11-30 13:25:10.8] DEBUG: RunShellCommand: -SERIAL- setprop "debug.mono.extra" "debug=127.0.0.1:8816,timeout=1448918739,loglevel=0,server=y"
[2015-11-30 13:25:10.8] DEBUG: RunShellCommand: -SERIAL- am start -a "android.intent.action.MAIN" -c "android.intent.category.LAUNCHER" -n "iSurvey.Android/md5f94fbf9c34d9e191fe8291efc268f13b.MainActivity"
[2015-11-30 13:25:11.8] DEBUG: RunShellCommand: -SERIAL- ps
[2015-11-30 13:25:11.9] DEBUG: GetLogCat: logcat -v time "dalvikvm:S" "ActivityThread:S" "mkestner:S" "MonoDroid-Debugger:S"
[2015-11-30 13:25:11.9] DEBUG: RunShellCommand: -SERIAL- logcat -v time "dalvikvm:S" "ActivityThread:S" "mkestner:S" "MonoDroid-Debugger:S"
[2015-11-30 13:25:12.9] DEBUG: RunShellCommand: -SERIAL- ps
[2015-11-30 13:25:14.1] DEBUG: RunShellCommand: -SERIAL- ps
[2015-11-30 13:25:15.2] DEBUG: RunShellCommand: -SERIAL- ps
[2015-11-30 13:25:15.4] DEBUG: RunShellCommand: -SERIAL- setprop "debug.mono.extra" ""
[2015-11-30 13:25:15.4] DEBUG: RunShellCommand: -SERIAL- am force-stop iSurvey.Android
Comment 5 Kent Green [MSFT] 2015-12-11 21:45:47 UTC
Possibly related to this bug: Bug 35798. 

Our QA team would like to know if you're using a Nexus 6p or 6, as the crash in bug 35798 only affects this year's 64bit Nexus devices as far as we know. 

It would also be helpful to know if adding arm64-v8a to the supported ABIs list is effective for working around the issue.
Comment 6 Pete Schmitz 2015-12-11 22:27:23 UTC
My phone is the original Nexus 6. The problem exists despite arm64-v8a being enabled on supported ABIs (it was already enabled).

If there are any configurations you would like me to test, let me know.
Comment 7 William Grand 2015-12-14 21:19:53 UTC
I experience the same issue on the Nexus 5X.
Comment 8 Maarten Wijnants 2015-12-16 09:03:09 UTC
I'm also getting this error on my Moto X Style after upgrading to Android 6.0.

Sometimes it happens right after deployment, other times the app starts normaly but crashes when 'Navigation.PushModalAsync(mainPage);' is called. It doesn't always crash on a that PushModalAsync though, so it might be the second or third time I perform the same action in the app.
Comment 9 Ramon 2015-12-16 18:17:25 UTC
I'm seeing the same issue with my Nexus 5X as well.

=== Xamarin Studio ===

Version 5.10.1 (build 6)
Installation UUID: b16d3c72-aa1f-4295-962c-abce68a54758
Runtime:
	Microsoft .NET 4.0.30319.18444
	GTK+ 2.24.23 (MS-Windows theme)
	GTK# 2.12.30

=== Xamarin.Profiler ===

Not Installed

=== Xamarin.Android ===

Version: 6.0.0 (Business Edition)
Android SDK: C:\Program Files (x86)\Android\android-sdk
	Supported Android versions:
		2.3   (API level 10)
		4.0.3 (API level 15)
		4.1   (API level 16)
		4.2   (API level 17)
		4.3   (API level 18)
		4.4   (API level 19)
		5.0   (API level 21)
		5.1   (API level 22)
		6.0   (API level 23)

SDK Tools Version: 24.4.1
SDK Platform Tools Version: 23.1

SDK Build Tools Version: 23.0.1


Java SDK: C:\Program Files\Java\jdk1.7.0_17
java version "1.7.0_17"
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)

=== Xamarin Android Player ===

Not Installed

=== Build Information ===

Release ID: 510010006
Git revision: 0b60eecdb531933734519c13257d16a780274aab
Build date: 2015-12-04 19:20:22-05
Xamarin addins: 9876fd7c9837977178411ec7375b4352c0a0d6af
Build lane: monodevelop-windows-cycle6-baseline

=== Operating System ===

Windows 6.1.7601.65536 (64-bit)
Comment 10 Przemysław Raciborski 2015-12-16 18:45:18 UTC
I get this crash on Nexus 5 device + Android Visual Studio Emulators (less often there though).

I think it is raised more often when there is a lot of concurrent GC operations performed (but that's just my guess).
Comment 11 Chase Florell 2015-12-16 23:15:38 UTC
The solution is as follows.

Go into your Application Properties and change "Target Android Version" to "23" explicetly.

There seems to be a bug in that when set to "Use Compile using SDK version", the manifest doesn't actually identify "23" anywhere. I'm not exactly sure what API is actually being targeted with that setting.

Essentially, if you have `Use Compile using SDK version`, your manifest will only reflect your Minimum Android Target (and my assumption is that the Target is ALSO that).

If you explicetly set the target to 23, you'll see the following added to your manifest.

android:targetSdkVersion="23"
Comment 12 Chase Florell 2015-12-16 23:22:36 UTC
May have spoken too soon. Now it's erroring when 23 is explicitly set too.
Comment 13 Andy 2016-01-13 19:53:19 UTC
Can confirm this is happening on my Nexus 5 when connected to the debugger. Makes it hard to ensure our stuff is all working on Android 6.0.
Comment 14 Mark Fredrickson 2016-01-15 17:52:43 UTC
I'm having the exact same issue with my Sprint LG G4 running Android 6.0 Marshmallow. The crashes seem to be totally random and not related to any specific code.

For what it's worth, the following has helped a little bit getting the debugger to start but it still crashes quite often, enough that I still have to use my G3 (running Android 5.01) for debugging. I have tried all the above suggestions with no luck.

From @MarkDownes:

Try closing VS, deleting all bin/obj files (I use a .bat file for this - sad that I have one for this, I know) and then reopen VS and the solution and try debugging again.
Comment 15 Jonathan Pryor 2016-01-16 03:41:35 UTC
Here's a quick summary of the problem:

The debugger is detaching because ART -- the *Android* Runtime/JVM -- is aborting the process:

> art/runtime/fault_handler.cc:117] Check failed: !initialized_

We believe that this is an ART bug, due in some part to how our debugger code is operating.

Unfortunately, from that perspective we'd want to have a concrete repro to file with Android, which is very difficult without saying "go use our product". (We've considered filing a bug along the lines of "FYI we're seeing this crash but we have no details on how to repro it," and concluded that wouldn't be entirely helpful.)

We've also looked into modifying our debugging code to try to avoid triggering this abort.

We haven't been successful so far on either course of action, though we are continuing investigations.
Comment 16 Kasper 2016-01-28 10:57:38 UTC
Perhaps you could reach out to realm. They seem to have struggled with the same issue last year. See the following issue:

https://github.com/realm/realm-java/issues/1689

It seems to be fixed in version 0.85, but it is not immediately obvious what was done from the commit logs.

Br, Kasper
Comment 17 Paul Read 2016-02-19 16:41:43 UTC
Any news? as still happening
Comment 18 Cristian González 2016-02-29 17:54:37 UTC
I'm having the same issue.
This happen while debugging my app with a Moto G 3rg Gen and running Android 6. And it fails after I launch the app with the same issue. I guess is an issue with the maps... 

Any news about this issue? The fix of Chase Florell, doesn't work for me. It keeps crashing the app. 

I'm using Xamarin Studio in a Mac. And my project is with Xamarin Forms 2.0
Comment 19 Mark Fredrickson 2016-03-01 05:30:23 UTC
@LukasPP suggested that checking "arm64-v8a" in the Advanced Tab of Android Build Options worked for him. And this also is working for me. Hallelujah!!!
Comment 20 Mark Fredrickson 2016-03-01 05:37:23 UTC
Oops didn't see the early post about trying the "arm64-v8a". Guess I should have read that and given it a go. Sorry about that. But I'm a happy camper now.
Comment 21 Andy 2016-03-02 01:05:53 UTC
Yeah!! That fixed it for me. I still think that's a bug in Xamarin. There should be a warning when building for API 23 without enabling arm64-v8a.
Comment 22 Andy 2016-03-11 18:11:09 UTC
Actually it is only fixed on an HTC M9, but it doesn't work on my Nexus 5 or LG Verizon G3.
Comment 23 Mark Fredrickson 2016-03-12 04:00:12 UTC
@Andy - I never had an issue with my Sprint G3, only the G4 which is now resolved. But I wouldn't be surprised if Verizon messed with your G3, they're known for doing that.
Comment 24 Seifer 2016-03-17 15:09:08 UTC
Enabling arm64-v8a fixed the crash on Nexus 5X, but breakpoints do NOT work...
Comment 25 Mark Fredrickson 2016-03-17 17:06:20 UTC
Yeah, sometimes they work and sometimes they don't. When they don't work I do a clean build or delete the bin/obj files like mentioned above. Sometimes I even put a breakpoint at the very start of my app which causes the other breakpoints to break. I also try uninstalling the app from my mobile device. But eventually I can get them to work.
Comment 26 Mark Fredrickson 2016-03-23 04:52:44 UTC
What seems to get breakpoints to work when the app hangs on a breakpoint is to stop debugging, restart VS, force stop the app, do a clean on the project, and then try again. BTW, I'm using VS 2013.
Comment 27 Seifer 2016-03-23 09:55:34 UTC
Putting the breakpoint to the start of the app also helped. (I'm using XS on Mac OSX)
Comment 28 Terry Moenkhaus 2016-03-24 02:08:52 UTC
I am so buried in a project (and ran into this bug) but am hoping that this will help someone form a proper test-case.

I can debug 100% of my app EXCEPT 1 part that creates a 2nd thread for processing of recorded data. I can debug, set and hit breakpoints anywhere in my app, except as soon as my code creates that 2nd thread (Task actually) the aforementioned message appears in my app log and the debugger quits (or more accurately gets booted by ART)

- Monk
Comment 29 Terry Moenkhaus 2016-03-24 02:56:17 UTC
Since I resolved MY issue, I figured I would point out what it was as maybe it could help create a test case.

MY issue was I was using Task.Delay(100). Assuming it was a drop in replacement for Thread.Sleep(100)...

Yea, it's not. Task.Delay(X) creates a new task that spins/waits for X milliseconds. So my processing thread was not waiting for 100 milliseconds and was therefore creating ALOT of Tasks. (fixed by using Task.Delay(100).Wait();)

A simple reproduction of this problem would be something like

while(true) {
    Task.Delay(100 * 1000); // Delay 100 seconds, but not actually.
}

This should cause a lot of threads to be created infinitely, which is apparently a really easy way to reproduce the issue in this bug report.

- Monk
Comment 30 Marek Habersack 2016-03-24 08:01:31 UTC
@Terry, thank you, this is most helpful! One more question - are you able to spot in logcat output the following line around the time your app crashes:

art/runtime/fault_handler.cc:117] Check failed: !initialized_

We believe the issue is that multiple threads trigger a race condition in both ART and our debugger code and the above message reflects the condition. I can reproduce the crash (a really hard one - without even a post-mortem stack trace) as the result of the failed assertion, but your suggestion might indeed make it easier to create a repro, thanks again!
Comment 31 Terry Moenkhaus 2016-03-24 08:15:36 UTC
Marek,

Thanks for the quick reply.

Unfortunately, after a rather long series of events (in regards to the project I am working on, among other things) I've decided a bit of a break was earned. Which led to one thing then another (involving alcohol,) at least this (thankfully) lead to the above realization!! That being said, I can not reliably answer you right now. I have book-marked this thread/bug-report and hopefully will remember it tomorrow and take a look and get a more in-depth answer for you.

- Monk

P.S. I do remember (We all know how "temporary" log output can be) there being quite a bit of info after the message mentioned above. I can easily remove my "fix" to reproduce the issue and get you more info tomorrow.
Comment 32 Nicholas Ventimiglia 2016-04-07 02:58:08 UTC
+1
Comment 33 Marek Habersack 2016-04-11 14:51:51 UTC
This bug is a combination of a bug condition in ART (fixed in the newer versions of it, although not completely, details below) and of the way Mono debugging on Android works.

Mono uses SIGSEGV to implement single-stepping (before anyone asks - this is a good way to jump out of managed code into the native one - the segfault handler takes over and proceeds accordingly) which, unfortunately, clashes with the segfault handler inside ART. The ART handler attempts to be smart and avoid nested segfaults in *Java* generated code. It does that by unhooking ART signal handler when running generated code and restoring the original handler for the duration of the generated code run, then plugging its own handler back in. This bug is triggered by an assumption in ART that the segfault handler will *always* be swapped out while Java generated code runs, which is obviously not the case with Xamarin.Android. The buggy version thus calls the ART handler initialization *twice* and thus the assertion which is the subject of this bug. Newer versions of ART (I checked master) fix the issue almost completely - they just leave a very tiny race condition which *may* be hit by Mono sometimes. Unfortunately, I don't see a way to fix that race condition in ART so we'll have to live with it (but do read on).

The workaround (and a long-term fix for the issue) is to use software breakpoints implemented by the Mono runtime. Those breakpoints don't use the SIGSEGV mechanism but instead inject CPU-specific code to single-step. Transitioning to software breakpoints is a long-term goal for the Mono runtime on the supported platforms. Unfortunately, there is a bug in the currently released versions of Mono which makes the software breakpoints fail on Linux and ARM machines - thus on Android. 

All of the issues we found with the software breakpoints are fixed in the upcoming Cycle 7 Xamarin.Android alpha. This release will default to software breakpoints so you should no longer see the assertion and you should be able to debug your applications without issues.

If you do see the assertion, however, it probably means that some other native code mapped into the Xamarin.Android app segfaults and triggers the assertion.
Comment 34 Peter Collins 2016-04-15 15:11:53 UTC
*** Bug 35798 has been marked as a duplicate of this bug. ***
Comment 35 Peter Collins 2016-04-15 17:14:54 UTC
This no longer reproduces for me using the current Beta (monodroid/cycle7/b4be22e9).
Comment 36 Mike Rowley 2016-06-09 02:17:14 UTC
Can someone at Xamarin give us an idea of the status of this?

If its fixed, what version is it fixed in?  

It typically takes me 3-4 starts of the app to actually get it to run, its killing productivity.

I am still seeing this constantly with the following:
Xamarin   4.0.3.214 (0dd817c)
Xamarin.Android   6.0.3.5 (a94a03b)
Xamarin.iOS   9.6.1.8 (3a25bf1)
Comment 37 Jonathan Pryor 2016-06-15 02:30:53 UTC
@Mike: This should be fixed in Xamarin.Android 6.1, currently stable:

https://developer.xamarin.com/releases/android/xamarin.android_6/xamarin.android_6.1/#Enable_soft_breakpoints_by_default

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