SIGSEGV crash when trying to Debug app with Xamarin.Android SDK 11.0.0.3 #4983
Comments
|
Same issue here. I had to manually roll back just the Xamarin.Android extension for Visual Studio for now, after I attempted a repair of VS. |
|
Actually, here's what I simplified the workaround down to:
In my case I'm only building for Perhaps this helps in the process of identifying what's going wrong here and allows others to work around for now. |
|
@tipa @bddckr could you please attach full logcat output for the crashed sessions? But please record it after first issuing the following commands: > adb shell setprop debug.mono.log default,assembly,timing=bare
> adb logcat -G 16M
> adb logcat -c
# Run the app here
> adb logcat -d > log.txtThanks! |
|
Ignore that this is from a Pico Neo 2, a standalone VR device 😉 log.txt Looks like it's having issues finding
|
|
Same issue for me when I updated from VS 16.6 to VS 16.7 and using Android 11. |
Thanks @bddckr, after replacing the folder to the previous one, it works well. |
Many thanks for the workaround guys - that's got me up and running again until fix has been found! |
|
Everyone experiencing this, do you happen to be using a device/emulator with Android 10 (API 29) by chance? If yes, could you please try with API 28 (or earlier), instead and see if you still experience the issue? |
With API 29 - issue with both emulator and device. |
|
Crashes on API27 with emulator created by VS 2019 v16.7 still see: 'Could not load library: Library '/system/lib/libmonodroid.so' not found.'. ===================== |
|
@tschlarman override means fastdeployment. What happens if you uncheck this in android app properties? |
|
Same bad thing. 08-07 08:55:23.157 D/Mono ( 4818): Assembly Ref addref System[0xe6e203a0] -> mscorlib[0xe6e1e180]: 4 SEGV |
|
Thanks for reporting everybody! It appears to be a bug in Android 10 on both devices and emulators and at least Android 9 issue on devices. The issue is as follows:
What happens here, however, is that Android 10 (and 9, for devices - possibly other versions/combinations too) will correctly accept the It follows that we can't trust the flag and need another way to deal with the situation. I have the fix planned, working on implementing it ASAP. As a workaround, you can set |
|
Thanks @grendello I will confirm that it does work on Android 10 emulators. So what happened in Xamarin Android between VS 16.6.x and VS 16.7 that broke this? Was Android previously not trusted to do the right thing, and in 16.7 someone decided to trust Android's flag? |
|
I can confirm the above (setting Thanks! |
|
@tschlarman it's not a Xamarin.Android bug. All of the machinery has worked for nearly past two years, we modiied the code over a year ago and that's about it. It's worked reliably until this release. It's without a doubt an Android bug, but it might be triggered by some Android update delivered to Android 9 devices, but not emulators, and present (or added in some update) in all Android 10 versions. |
|
@grendello Just curious. Seems like it might have been something in the 16.7 update since that was the only think I can think of that changed. We have a work around and a fix in the works so that's all that matters. Thanks for your work and explanation. |
|
@tschlarman no, really - there wasn't any change that could have mattered. The flag being incorrectly set is what threw it off - no tests or testers ever hit it before |
|
This appears to be a bug somewhere between the Android package manager (which installs the application) and the runtime/loader (which should set the flag as appropriate), possibly buggy data in the app database? Many Android components are now updatable via the Play Store, so the update with the bug could have found its way to Android 9 devices (the assumption supported by the fact that Android 9 emulators work fine - they don't receive updates via the usual chanels) |
|
@grendello It's all good. Just seemed odd that several of us all ran into after upgrading to 16.7, but worked fine on 16.6.x the day before. I guess a new test case for your tests. 😄 |
|
It appears that the reason only 16.7 update saw this issue is the update of manifest-merger, which with that version started to set |
|
@grendello Thanks for the follow-up. Nice to know where it came from and why it suddenly (appeared to) show up with 16.7. Sounds like something that should be reported to Google so that it can be fixed and hopefully, your workaround won't be necessary at some point. |
grendello
added a commit
to grendello/xamarin-android
that referenced
this issue
Aug 10, 2020
Fixes: dotnet#4983 Context: https://developer.android.com/reference/android/content/pm/ApplicationInfo.html#FLAG_EXTRACT_NATIVE_LIBS Xamarin.Android has supported the [extractNativeLibs][0] attribute (introduced by Android API 23) on the `<application>` element in AndroidManifest.xml since 95ca102, with a single significant modification in feb9ea2 after we discovered that Android build system can set the flag when constructing the APK after we are done packaging. feb9ea2 introduced a runtime check to see whether the `FLAG_EXTRACT_NATIVE_LIBS` is *not* set, which meant that the native libraries are to stay in the APK file and we need to set up our DSO search paths to point to the inside of APK files instead of the traditional filesystem location. However, it appears that Android 10 (API 29, on both devices and in emulators) and Android 9 (API 28, on *just* the devices) broke the `FLAG_EXTRACT_NATIVE_LIBS` semantics in that it is possible for the flag to be *set* (which means libraries are *extracted*) with the libraries not extracted from APKs, thus breaking the logic implemented in feb9ea2. It is possible that other Android versions are affected as well, which means we can no longer trust the flag value and need to implement another way of checking whether the libraries are on the filesystem or in the APK. The simplest approach is to check for existence of a known library in the filesystem location, regardless of the API level, and assume the flag is *not* set if the shared library is missing. This is what this commit implements. The check is performed once on application startup, thus minimizing the performance impact. [0]: https://developer.android.com/guide/topics/manifest/application-element#extractNativeLibs
grendello
added a commit
to grendello/xamarin-android
that referenced
this issue
Aug 10, 2020
Fixes: dotnet#4983 Context: https://developer.android.com/reference/android/content/pm/ApplicationInfo.html#FLAG_EXTRACT_NATIVE_LIBS Xamarin.Android has supported the [extractNativeLibs][0] attribute (introduced by Android API 23) on the `<application>` element in AndroidManifest.xml since 95ca102, with a single significant modification in feb9ea2 after we discovered that Android build system can set the flag when constructing the APK after we are done packaging. feb9ea2 introduced a runtime check to see whether the `FLAG_EXTRACT_NATIVE_LIBS` is *not* set, which meant that the native libraries are to stay in the APK file and we need to set up our DSO search paths to point to the inside of APK files instead of the traditional filesystem location. However, it appears that Android 10 (API 29, on both devices and in emulators) and Android 9 (API 28, on *just* the devices) broke the `FLAG_EXTRACT_NATIVE_LIBS` semantics in that it is possible for the flag to be *set* (which means libraries are *extracted*) with the libraries not extracted from APKs, thus breaking the logic implemented in feb9ea2. It is possible that other Android versions are affected as well, which means we can no longer trust the flag value and need to implement another way of checking whether the libraries are on the filesystem or in the APK. The simplest approach is to check for existence of a known library in the filesystem location, regardless of the API level, and assume the flag is *not* set if the shared library is missing. This is what this commit implements. The check is performed once on application startup, thus minimizing the performance impact. [0]: https://developer.android.com/guide/topics/manifest/application-element#extractNativeLibs Co-Authored by: Jonathan Peppers (@jonathanpeppers)
|
|
|
I can confirm the above (setting android:extractNativeLibs=true) works with Device (Pixel 4) and API 29. Thank you for all your support! |
brendanzagaeski
removed
the
vs-sync
Tested on macOS using VS 8.7. I can confirm that it works where 11.0.0.3 did not work before. |
jonpryor
pushed a commit
that referenced
this issue
Aug 12, 2020
…4993) Fixes: #4983 Context: https://developer.android.com/reference/android/content/pm/ApplicationInfo.html#FLAG_EXTRACT_NATIVE_LIBS Android API-23 added support for [`//application/@android:extractNativeLibs`][0], which allows an app to state that native libs within the `.apk` should *not* be extracted as part of app installation, to save on overall installation size. Support for `extractNativeLibs` was added in 95ca102 and feb9ea2. Unfortunately, we have determined that on some Android 9 devices and Android 10 devices & emulators, the [`FLAG_EXTRACT_NATIVE_LIBS`][1] check used in commit feb9ea2 doesn't work as intended or expected: boolean embeddedDSOsEnabled = (runtimePackage.flags & ApplicationInfo.FLAG_EXTRACT_NATIVE_LIBS) == 0; What we observe on the offending devices is that `embeddedDSOsEnabled` is False when `//application/@extractNativeLibs` is false, which is the *opposite* of what we expect. Consequently, when we *should* be looking for native libs within the `.apk`, we don't! The result is that we can't find `libmonodroid.so` ('cause it's in the `.apk`, not on disk): DllImport error loading library '__Internal': 'Could not load library: Library '/system/lib/libmonodroid.so' not found.'. Note the *path* that is being checked: `/system/lib/libmonodroid.so`, because we aren't checking within the `.apk`, so we "fallback" to various other paths, including `/system/lib`, none of which have `libmonodroid.so`. The result is that, eventually, the app crashes during startup: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x6f63736d in tid 7607 (…), pid 7607 (…) It is possible that other Android versions are affected as well, which means we can no longer trust the flag value and need to implement another way of checking whether the libraries are on the filesystem or in the `.apk`. Work around this Android issue by checking for the presence of a known library in a filesystem location, regardless of the API level. Specifically, check for the presence of `libmonodroid.so`. If `libmonodroid.so` is not found, assume that all libraries should be loaded from the `.apk`, as if `//application/@extractNativeLibs`=false. The check is performed once on application startup, thus minimizing the performance impact. [0]: https://developer.android.com/guide/topics/manifest/application-element#extractNativeLibs [1]: https://developer.android.com/reference/android/content/pm/ApplicationInfo#FLAG_EXTRACT_NATIVE_LIBS Co-Authored by: Jonathan Peppers (@jonathanpeppers)
|
Thanks @grendello, it works form me in mi mac and windows machine. But I have another problem that this fixes won't fix. All apk I release won't install. I don't understand if I had to change anything in Android projects, maybe, but I don't know how. It occurs in windows and mac machines... |
4 tasks
|
@Strifex MvvmCross?? |
This fix works for me on Windows. Before I had to use the AndroidManifest.xml workaround mentioned above. Thanks for releasing that installer! |
|
@nate123456 please keep in mind that it's a preview of a preview, really :) |
|
Ok, the fix is rolled out to public with 16.7.2 update:
https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes#16.7.2 |
|
Release status update The corresponding version is also now available in Visual Studio 2019 for Mac version 8.7.3. A new Release version of Xamarin.Android has now been published that includes the fix for this item. Fix included in Xamarin.Android SDK version 11.0.2.0 Fix included on Windows in Visual Studio 2019 version 16.7.2. To get the new version that includes the fix, check for the latest updates or install the most recent release from https://visualstudio.microsoft.com/downloads/. Fix included on macOS in Visual Studio 2019 for Mac version 8.7.3. To get the new version that includes the fix, check for the latest updates on the Stable updater channel. |
|
Note that the fix for this issue makes it so Xamarin.Android is now compatible with This means that although |
|
I had to revert that preview extension (version 11.0.99) provided here to work around the issue, in order to get it to the version just released, 11.0.2.0. |
Any update on this? |
This is unlikely to be related to this issue since it happens on installation and not run time. Please open a new issue and provide a full binary build log (create with /cc @Shantydroid |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
and others
Steps to Reproduce
Expected Behavior
No crash
Actual Behavior
Splash screen shows, then app crashes.
Happened on two separate Windows machines, on both physical device and emulator.
Version Information
Log File
The text was updated successfully, but these errors were encountered: