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.
#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)
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?
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
Xamarin 184.108.40.206 (3e1ef9e)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.
Xamarin.Android 220.127.116.11 (ce955cc)
Visual Studio extension to enable development for Xamarin.Android.
*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
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
Any updates on this one?
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?
That solution works. Thanks.
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?