Bug 48475 - App got crashed on Android 7.0 on Nexus 9
Summary: App got crashed on Android 7.0 on Nexus 9
Status: RESOLVED FIXED
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: unspecified
Hardware: PC Windows
: --- blocker
Target Milestone: ---
Assignee: Jimmy [MSFT]
URL:
Depends on:
Blocks:
 
Reported: 2016-11-30 21:46 UTC by Hannah Nguyen
Modified: 2017-08-03 14:03 UTC (History)
10 users (show)

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

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:
Status:
RESOLVED FIXED

Description Hannah Nguyen 2016-11-30 21:46:14 UTC
#Tried to build the app targeting Android 7.0 (API 24). It crashed when launching.  I tried with different apps even with a brand new blank one and got the same errors. I selected all supported architectures and it still threw the same exception.


# Expected behavior


# Actual behavior


# Supplemental info (logs, images, videos)
Could not unwind with `libunwind.so`: dlopen failed: library "/data/app/.../lib/arm/libunwind.so" not found
11-30 10:30:45.568 E/mono-rt (26710): 	Could not unwind with `libcorkscrew.so`: dlopen failed: library "/data/app/.../lib/arm/libcorkscrew.so" not found
11-30 10:30:45.568 E/mono-rt (26710): 
11-30 10:30:45.568 E/mono-rt (26710): 	No options left to get a native stacktrace :-(

# Test environment (full version information)
Comment 1 Samantha Houts [MSFT] 2016-11-30 23:33:44 UTC
Do you have the same problem with a Xamarin.Android app, or just with a Xamarin.Forms app? Are you using Visual Studio? Are you using a device or an emulator?
Comment 2 Hannah Nguyen 2016-12-01 16:12:30 UTC
Sorry I had problem with Xamarin.Android app only. I am using an actual device. I am using Microsoft Visual Studio Professional 2015. Following are details:
Version 14.0.25431.01 Update 3
Microsoft .NET Framework
Version 4.6.01055

Xamarin   4.2.1.58 (3e1ef9e)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin.Android   7.0.2.37 (ce955cc)
Visual Studio extension to enable development for Xamarin.Android.
Comment 3 Hannah Nguyen 2016-12-01 16:20:03 UTC
*Sorry it's Xamarin.Forms. People are having same problem like me https://forums.xamarin.com/discussion/82036/android-7-xamarin-forms-in-release-could-not-unwind-with-libunwind-so
Comment 4 FieldstrikeMobile 2016-12-06 16:34:17 UTC
This is a real problem. It's pretty much Bricked our Nexus 9 in the office (because we can no longer deploy our app to it)

Using Visual Studio Update 3
With latest Xamarin version

Deploying Xamarin.Forms application
Comment 5 Hines Vaughan III 2017-03-23 15:10:29 UTC
Any updates on this one?
Comment 6 Hannah Nguyen 2017-04-26 16:04:24 UTC
Any updates?
Comment 7 Jimmy [MSFT] 2017-04-26 17:46:42 UTC
Hey all, this issue may be the same as bug 46482 which is a bug in Mono, not Xamarin.Forms. 

Since that report is private, I'm copying a comment from one of the engineers below. They suggest including arm64-v8a as a target architecture as that seems to resolve the issue on the Nexus 9 device. Can you try this and confirm it works for you as well?

====

Thanks again Matthias.  Unfortunately, I'm out of ideas, and I can't blame anything but the hardware. The situation we see is too weird. We segfault at offset 0xdda60 ("str sl, [r4]"), but really we should already segfault at offset 0xdda2c ("ldrge   sl, [r4, #8]!").  So I suspect two things why this could happen:

(1) The instruction at dda2c fails to do the post-increment correctly for *whatever* reason.

(2) Something along the execution path corrupts the stackslot, where r4 is saved, in such a way that it *exactly* masks it with 0xf. Everything else on the stack looks fine, so this is sort of very unlikely to be honest.

This only happens on a very specific device: The Nexus 9 is the only device that was ever shipped with the Tegra K1 T132.  I suspect an issue in the binary translation layer of armv7 instruction set to the internal micro-ops of the CPU.  I tried to stress test the instruction in question (see https://github.com/lewurm/ldrinsntest), however I was not able to trigger a crash.  So either, I'm missing some context in order to trigger the bug or I'm on a completely wrong track.

That said, even if we could proof that it is indeed a hardware issue, the workaround is also non-trivial (it would then either need a fix in gcc or require a microcode update by the chip vendor). 

TL;DR: Since this bug doesn't happen using arm64-v8a, is using that as a target architecture a viable workaround for you?

====
Comment 8 Hannah Nguyen 2017-04-27 20:36:47 UTC
That solution works. Thanks.
Comment 9 Matthew Sebastian 2017-06-06 14:00:57 UTC
We have a number of apps using ESRI's mapping components that have known crashing issues with ARM64-v8a. Not that the population of Nexus 9 devices is high, is this bug likely to be solved upstream at any point?
Comment 10 robins 2017-08-03 14:03:43 UTC
+1