Hi, I still getting this exception in my android app on Samsung S7. Turning off `arm64-v8a` does not help me. And the weirdest thing that this ExecutionEngineException SIGILL is throwing from different pieces of my code, in different moments of app work (on start, on login to app, on animation, etc) and with different CallStack, so i can not locate the problem piece of code.

Hi, do you know if this crash happens with an hello world sample app?

Hi, it's not happening with HW app. I've described the problem here also http://forums.xamarin.com/discussion/64215/app-doesnt-run-on-samsung-s7-sometimes

My problem described more here https://bugzilla.xamarin.com/show_bug.cgi?id=40486

Same problem here with Samsung S7 (SM-G930F), Android 6.0.1.

Xamarin Studio Enterprise
Version 5.10.3 (build 51)

Project uses Xamarin.Forms 2.0.1.6505, Xamarin.Insights and targets API 23.

It doesn't seem to be related to Insights, because I removed it and it kept crashing.

One of our apps is stable with latest alpha (Xamarin.Android 6.2) and WITHOUT armebi64-v8 support (v7 and x86 only).

Some of our users are hitting this exception in our production version.

Xamarin 5.10.3
Xamarin.Android
Version: 6.0.4.0 

Devices:
Samsung Galaxy S6 Edge
Samsung Galaxy Note 5
Samsung Galaxy S6 Active

Unfortunately, there's no stacktraces (null) and I don't see any consistent events leading into this exception.

Problem still occurs on Xamarin.Android 6.1.1.1.
Is there any fix yet?

We're getting this error reported on Insights too for Android - also after releasing with Cycle7.

=== Stack trace ===

System.ExecutionEngineExceptionSIGILL
at System.RuntimeTypeHandle.IsGenericVariable(RuntimeType)

System.ExecutionEngineExceptionSIGILL
null

=== Xamarin Studio ===
Xamarin Studio Enterprise
Version 6.0.1 (build 9)
Runtime:
	Mono 4.4.1 (mono-4.4.0-branch-c7sr0/4747417) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)


=== Xamarin.Android ===
Version: 6.1.1.1 (Xamarin Enterprise)
Android SDK: /Users/dla/Library/Developer/Xamarin/android-sdk-macosx
	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)
		4.4.87 (API level 20)
		5.0    (API level 21)
		5.1    (API level 22)
		6.0    (API level 23)

SDK Tools Version: 25.1.6
SDK Platform Tools Version: 23.1
SDK Build Tools Version: 23.0.3

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)

=== Device provisioning ===

It seems like this issue mainly occurs for newer versions of Android and only for Samsung devices:
Android M
Android 5.0
Android 5.1

SM-G925f
SM-G920f
SM-G935f
SM-G930f
SM-G850f

Guys

any update on this?

We do have this error being reported with a reasonably high frequency on several devices. It does not happen only on s7.
We noticed the following:

1 - supporting amr64-v8a ABI is a disaster for us. The app crashes with a crazy frequency. By removing it, it minimizes a lot the probability of a crash;

2 - It happens is several OS;

3 - i was going through the logs and did not see any 32 bit device with this crash. At least it seems to be much more frequent (if not exclusive) in 64 bit processors;

4 - The error seems to be quite random. We do have logs with stack traces in several different places. This suggest some memory corruption screwing GC;

5 - this issue is being propagated through more than one release. In current stable 6.1.1.1 is happening and it was happening before.

Hi,

I am waiting for the Samsung Galaxy S7 device to be provisioned to me so I can take a look at the issue.

Hi,

I'm getting this problem alot while trying to develop our first app. I can't add much info apart from say I'm using a Samsung Galaxy S7 (SM-G930F) and I'm seeing it most while doing async network operations. 

Cheers
Tim

Adding stacktrace from our application to add some information to it:

Android: 6.0.1
Manufacturer: samsung
Model: SM-G930F
Date: Fri Jul 08 15:56:50 GMT+02:00 2016

java.lang.Throwable: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ExecutionEngineException: SIGILL
  at Java.Lang.Throwable.get_Handle () <0x7f8007bc70 + 0x00000> in <filename unknown>:0 
  at Java.Interop.Runtime.IsGCUserPeer (IJavaObject value) <0x7fa099dec8 + 0x0003f> in <filename unknown>:0 
  at Java.Interop.TypeManager.CreateInstance (IntPtr handle, JniHandleOwnership transfer, System.Type targetType) <0x7fa09bc518 + 0x00457> in <filename unknown>:0 
  at Java.Lang.Object.GetObject (IntPtr handle, JniHandleOwnership transfer, System.Type type) <0x7fa09bbc08 + 0x0033f> in <filename unknown>:0 
  at Java.Lang.Object._GetObject[T] (IntPtr handle, JniHandleOwnership transfer) <0x7fa09bba80 + 0x0004b> in <filename unknown>:0 
  at Java.Lang.Object.GetObject[T] (IntPtr handle, JniHandleOwnership transfer) <0x7fa09bb838 + 0x0002b> in <filename unknown>:0 
  at Java.Lang.Throwable._GetInnerException (IntPtr handle) <0x7f8007b858 + 0x00107> in <filename unknown>:0 
  at Java.Lang.Throwable..ctor (IntPtr handle, JniHandleOwnership transfer) <0x7f8007b590 + 0x0002f> in <filename unknown>:0 
  at Java.Lang.Exception..ctor (IntPtr javaReference, JniHandleOwnership transfer) <0x7f8007b4d8 + 0x00023> in <filename unknown>:0 
  at Java.Lang.RuntimeException..ctor (IntPtr javaReference, JniHandleOwnership transfer) <0x7f8007b420 + 0x00023> in <filename unknown>:0 
  at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (System.Reflection.MonoCMethod,object,object[],System.Exception&)
  at System.Reflection.MonoCMethod.InternalInvoke (System.Object obj, System.Object[] parameters) <0x7fa09b8548 + 0x00033> in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at System.Reflection.MonoCMethod.InternalInvoke (System.Object obj, System.Object[] parameters) <0x7fa09b8548 + 0x00080> in <filename unknown>:0 
  at System.Reflection.MonoCMethod.DoInvoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) <0x7fa099a978 + 0x000cb> in <filename unknown>:0 
  at System.Reflection.MonoCMethod.Invoke (BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) <0x7fa099a920 + 0x00037> in <filename unknown>:0 
  at System.Reflection.ConstructorInfo.Invoke (System.Object[] parameters) <0x7fa099a8b0 + 0x0005b> in <filename unknown>:0 
  at Java.Interop.TypeManager.CreateProxy (System.Type type, IntPtr handle, JniHandleOwnership transfer) <0x7fa0999798 + 0x00153> in <filename unknown>:0 
  at Java.Interop.TypeManager.CreateInstance (IntPtr handle, JniHandleOwnership transfer, System.Type targetType) <0x7fa09bc518 + 0x002db> in <filename unknown>:0 
  at Java.Lang.Object.GetObject (IntPtr handle, JniHandleOwnership transfer, System.Type type) <0x7fa09bbc08 + 0x0033f> in <filename unknown>:0 
  at Java.Lang.Object._GetObject[T] (IntPtr handle, JniHandleOwnership transfer) <0x7fa09bba80 + 0x0004b> in <filename unknown>:0 
  at Java.Lang.Object.GetObject[T] (IntPtr handle, JniHandleOwnership transfer) <0x7fa09bb838 + 0x0002b> in <filename unknown>:0 
  at Java.Lang.Thread+IUncaughtExceptionHandlerInvoker.n_UncaughtException_Ljava_lang_Thread_Ljava_lang_Throwable_ (IntPtr jnienv, IntPtr native__this, IntPtr native_thread, IntPtr native_ex) <0x7f8007b2c0 + 0x0006b> in <filename unknown>:0 
  at (wrapper dynamic-method) System.Object:fa7da85c-d986-4b95-a23c-3fb7bbd29c63 (intptr,intptr,intptr,intptr)
	at android.runtime.UncaughtExceptionHandler.n_uncaughtException(Native Method)
	at android.runtime.UncaughtExceptionHandler.uncaughtException(UncaughtExceptionHandler.java:37)
	at com.google.android.gms.analytics.ExceptionReporter.uncaughtException(Unknown Source)
	at com.google.android.gms.analytics.ExceptionReporter.uncaughtException(Unknown Source)
	at net.hockeyapp.android.ExceptionHandler.uncaughtException(ExceptionHandler.java:120)
	at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:693)
	at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:690)

We're seeing this exception regularly in Xamarin Insights. It mostly occurs on startup, but also occurs in seemingly arbitrary places. The startup crashes don't have any accompanying stack trace, but the others do.

Turning off 'arm64-v8a' seems to have improved the issue, but it still occurs.

If you email me I can provide a link to Xamarin Insights which will list the issues. ian.newson(at)xibis.com.

We have the same problem. Updates?

Is there an update on this issue? The crashes are getting out of hand.

This is urgent! We need an update on this issue.

Same problem on s7. Waiting for update.

Turning off 'arm64-v8a' does NOT seem to improve stability on SamsungS7.
App crashes seemingly randomly. Always with a SIGILL error.

## Status update for users watching this bug

Some candidate fixes for this issue are included in today's Cycle 8 Beta update:

- Xamarin.Android 6.2.0.47
- XamarinVS 4.2.0.584

*** Bug 40486 has been marked as a duplicate of this bug. ***

Has anyone affected by the problem had the chance to try out the beta Brendan Zagaeski  mentions?

Building our first LOB app in Xamarin, everything looking good in emulator, even when debugging over USB with the Samsung S7 (SM-G930F), however deploying it and just running without the debugging I randomly have the application crash.

Glad it isn't just me, haven't had a chance to try the beta yet.

Same thing here with a customers S7 model SM-G930W8. Going to build a Cycle 8 version and send it to him. Will update when I hear back.

@Mark - thank you very much. We'd definitely appreciate a confirmation.

We've also been getting this crash, I'll also push out a beta 8 channel and see what happens.

Andi, I tried the beta Brendan Zagaeski mentioned but it did not fix the problem. Since there is a new beta out since very recently, I will try again.

Don't know if it's related but I'm using Xamarin.Forms 2.3.1.114 and my Android project is showing me Xamarin.Android.Support.* updates (to version 23.4.0.1) which I cannot upgrade since there is no compatibility with Xamarin.Forms.

Previous beta release (the one reported by Brendan) has crashed many times yesterday, as reported by HockeyApp.

Devices: SAMSUNG SM-G935F and SAMSUNG SM-G930F. Both are Samsung Galaxy S7 (edge and non-edge I guess) and have Android 6.0.1 installed.

Xamarin caused by: android.runtime.JavaProxyThrowable: System.ExecutionEngineException: SIGILL

I haven't heard back from my users yet. I think they're taking the holiday weekend off but it doesn't sound like good news for them. I'll check with them tomorrow.

I just got a report that even the latest beta release does not solve this issue on Samsung S7 :(

Hate to be that guy, but could we get an update from Xamarin? This has been going on for months with Samsung devices and isn't just SIGILL either, it also produces weird NullReference and ArgumentNull exceptions on these devices.

Does anyone experience this issue on a US-version of the Galaxy S7? the SM-G93?F is the "World" edition that is shipped with the Exynos 8890, while the US version is shipped with a Snapdragon 820. From what I can tell this issue has been reported only for the World edition so far.

I was able to reproduce the problem on a SM-G930F via Xamarin Test Cloud, here're some crash logs:
https://gist.github.com/lewurm/b5827a29aa0189dc16831241cb2c347a

It only happens on the SM-G930F and SM-G935F from our crash logs, sorry. We get around 5 logs a day, which is a lot considering people only use our app in urgent personal safety situations...

Actually, I just found a SIGILL for a SM-G920I.

The two that have occurred with my customers are the SM-G935F (Global) and the SM-G930W8 (Canada using the MediaTek Helio processors).

Pull request for master: https://github.com/mono/mono/pull/3549

Tested on a SM-G930F, very likely fixes it also for other models. As soon as this is reviewed and merged I'll backport it to mono 4.6.

backport for 4.6: https://github.com/mono/mono/pull/3554

Encountered de SIGILL on the SM-G930FD (Samsung S7, Taiwan)

Great to see this has been back ported. When can we expect a stable Xamarin.Android release with the fix?

Here's a link to an unofficial build (mac):
https://bosstoragemirror.blob.core.windows.net/wrench/monodroid-mavericks-cycle8/7b/7b76cb80f666d73296f5a6924986a3813159bb2d/xamarin.android-7.0.0-19.pkg

It's basically what you have in the alpha channel including this fix (for reference, it's based on xamarin-android/7c0948ce4877f7b1edcffb97e2c86b28e6365e82).

Please let us know if this fixes the issue for you.  The fix will of course be included in upcoming releases.

I've never reproduced this in the lab, only in released builds, so I am a bit hesitant to release the alpha. I'll just be waiting for the next stable.

Guys we'll try to test it tomorrow. Our app with arm64 abi support was just crashing like hell in S7.
Thank you guys for your amazing work! 

To have a better notion of what was going on, please read Rodrigo Kumpera and Bernhard Urban article.

http://www.mono-project.com/news/2016/09/12/arm64-icache/

I'm a bit reluctant of releasing with beta version of the framework but I won't do that for alpha. I just downloaded the 7.0.0.18 which was released. Too bad this important fix is not simply backported/cherry-picked just as important security fixes would be. Anyway, will wait a bit longer.

After reading the the blog post on mono-project all I can say is well done and great work. I'm sure it was really satisfying to find and fix.

Due the our requiremnet being part of a saftey system we wont we looking to roll out an Alpha so we'll wait as well (but I may play if I get time)

Amazing work. We'll try it out once it reaches the stable channel.

Why is there no backport to the current stable version??

Guys

i think that Bernhard was talking about alpha by mistake. What is available today in all channels is the same. The link that he sent just replaces Xamarin.Android with this bug correction. In current stable you have 7.0.0.18 and you can download a and install a new version (7.0.0.19) to test it with in your apps and help us all confirming that this damn bug is dead.

In fact, thanks Manuel for the info. I double checked, Bernhard says the unofficial build is based on commit 7c0948ce4877f7b1edcffb97e2c86b28e6365e82 which happens to be one of the very last commits on the cycle-8 branch: https://github.com/xamarin/xamarin-android/commits/cycle8

So this is effectively a backport of the bug fix onto the beta branch. Will test it asap.

We did a few tests with the app supporting arm64-v8a ABI in a Samsung S7 and, so far, 0 crashes! :)

Sorry for the confusion: Yes, Manuel and Xavier are right, it's based on the C8 release.  Still, it didn't go through Q&A, therefore it's an unofficial build.

Thank you Manuel for testing! :)

Could someone elaborate on the process for installing the package on VS on a PC and XS on the Mac? - Thanks.

Yes, as Mark said, is there a VS installer package?

Hi, this series 8 stable release that was just released, does it include the fix?

We are expecting to have this fix in the Service Release 0 update to C8. There will be a stable release of this through the normal channels in the next week or two.

Bernhard's test package above is a Mac version. If you just download and double click it, it will replace the Xamarin.Android currently installed in your current version of Xamarin Studio. If you are using Visual Studio, we recommend waiting for Service Release 0.

Marking as resolved as the corresponding PR has been merged to master and mono-4.6.0-branch.

Verified fixed against monodroid/cycle8/7b76cb80f6, using a test case which had roughly a 75% failure rate before the fix was applied.

We are currently doing a release of our Android apps - is it possible to get a pre-release build of the Visual Studio package including this fix so we can release it now?

Whats the state of this fix? I pretty much cant run my app on the S7...

im a VS user..

Here's an unofficial link for a corresponding VS package:
https://bosstoragemirror.blob.core.windows.net/wrench/xvs-win-cycle8/f3/f3ee54cb437a78a79c331ec182b1e09e6043da62/Xamarin.VisualStudio_4.2.0.682.msi

Keep in mind that this specific build has had no formal testing or approval, so please use it at your own risk. We do not recommend shipping anything built with these test builds, either mine or that which Bernhard had provided in Comment #42.

Finally, as Andi mentioned in Comment #56, this fix will officially be made available to both Windows and Mac users via the public updater channels in the coming weeks.

Thanks Peter, I have decided to incur the risk of deploying this update now, we'll release again when the official build is available.

An official (but beta) version of C8SR0 containing the fix for this bug is now available through our Beta channel. See https://releases.xamarin.com/beta-preview-cycle-8-service-release-0/ for more information.

An official stable release fixing this bug is now available https://releases.xamarin.com/stable-release-cycle-8-service-release-0/

If you downloaded one of the official/beta builds above, please upgrade.

An official stable release fixing this bug is now available https://releases.xamarin.com/stable-release-cycle-8-service-release-0/

If you downloaded one of the official/beta builds above, please upgrade.

Bad news everyone, I'm still getting SIGILL with the new release, it's just much much rarer now:

Fatal Exception: java.lang.Throwable: System.ExecutionEngineException: SIGILL
       at System.Runtime.Remoting.Messaging.AsyncResult.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()(<128bb39fdc914b04b7c7b60d1350caf5>)
       at System.Threading.ThreadPoolWorkQueue.Dispatch()(<128bb39fdc914b04b7c7b60d1350caf5>)
       at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()(<128bb39fdc914b04b7c7b60d1350caf5>)

I'm also still getting other random weird crashes (which happen more often than the SIGILL).

https://bugzilla.xamarin.com/show_bug.cgi?id=45530

Raised a new issue against the new version: https://bugzilla.xamarin.com/show_bug.cgi?id=45609

I havnt upgraded yet - did u try installing the beta fix previously? This worked for me, i havnt crashed since, although i wouldnt say i have heaps of devices and hours spent testing. like other people might.

We never released the Beta version, only the official fix. Frequency of the issue appears to have reduced since the fix though.

Peter Collins 2016-09-16 17:39:42 UTC}
<beta link>

With this build, i went from crashing every launch to no crashes in a month. 

Previosulyu though, in other bugs, i have installed the beta and fixed the issue, then when upgading stable once it made its way there, i have hit issues again.

This is why im asking. The beta might work, but the stable might not. Do what u will with that info.

Thanks. What I did with that info was create another issue for the new release :)