-
Notifications
You must be signed in to change notification settings - Fork 528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Native Crash (SIGABRT): monoeg_g_usleep: clock_nanosleep () returned -1 #6600
Native Crash (SIGABRT): monoeg_g_usleep: clock_nanosleep () returned -1 #6600
Comments
It appears to be an issue with the Linux kernel on the version of Android you're using. The |
Yea makes sense to me. @steveisok maybe someone from your team can make the change. I can help out. |
Hi all, I've been experiencing the same issue related to clock_nanosleep() returning -1. I've done some investigations:
If you look at the implementation of this function https://android.googlesource.com/platform/bionic/+/faa0fdb/libc/arch-arm/syscalls/clock_nanosleep.S one can notice that it uses the errno mechanism to output errors through __set_syscall_errno https://android.googlesource.com/platform/bionic/+/ics-mr1-release/libc/bionic/__set_errno.c __set_syscall_errno will basically return -1 and set errno as the negated value returned by the Kernel code => return value of clock_nanosleep() is actually -1 uppon error and the actual error is in errno. This is contradictory to the POSIX clock_nanosleep() but it is how the function was implemented in the Bionic libc.
Hope this helps ! |
For some reason I can't assign @simonrozsival, but he's going to take on fixing this. |
The failure behavior of |
@simonrozsival unfortunately my use case involves custom hardware running Android 4.4.3, and I cannot upgrade the OS. Will the handling of the incorrect clock_nanosleep behavior still be implemented in Xamarin.Android? |
Hi @simonrozsival & all, |
@jfichtner I see. I'll open a PR which will handle the |
…64679) There used to be a bug in Android libc implementation of `clock_nanosleep`. The return value should be `errno` on errors but instead in it returns `-1` and sets `errno`. The libc (Bionic) bug [has been fixed](https://android-review.googlesource.com/c/platform/bionic/+/110652/) since Android 6 and newer but it causes problems to [customers who are unable to update Android on their devices](dotnet/android#6600 (comment)). Fixes dotnet/android#6600 * Account for incorrect implementation of clock_nanosleep in older Android libc * Shorten comments * Add g_clock_nanosleep function * Add remap definition * Fix build * Make sure the extra check runs only on Android * Make Windows builds happy * Try making wasm builds happy
@simonrozsival and @lambdageek I can't thank you enough for implementing this knowing that it only affects a small subset of users. This gives me a lot more confidence in using this product, in general! Kudos! |
@simonrozsival and @lambdageek thank you very much this will be huge also for us, we might finally be able to upgrade our build environment! |
…otnet#64679) There used to be a bug in Android libc implementation of `clock_nanosleep`. The return value should be `errno` on errors but instead in it returns `-1` and sets `errno`. The libc (Bionic) bug [has been fixed](https://android-review.googlesource.com/c/platform/bionic/+/110652/) since Android 6 and newer but it causes problems to [customers who are unable to update Android on their devices](dotnet/android#6600 (comment)). Fixes dotnet/android#6600 * Account for incorrect implementation of clock_nanosleep in older Android libc * Shorten comments * Add g_clock_nanosleep function * Add remap definition * Fix build * Make sure the extra check runs only on Android * Make Windows builds happy * Try making wasm builds happy
I tried to find this info on my own but I have not been able to find a product roadmap or release schedule that would indicate when this fix might be available in a Xamarin update. Can someone point me to any info that would allow me to determine this? Do I just need to keep an eye on the release notes? Thanks in advance. |
…ono#21433) Fixes dotnet/android#6600 Backported from dotnet/runtime#64679 and dotnet/runtime#65373 (cherry picked from commit 36daf03)
…osleep (#21435) * [Android] Workaround for invalid return value from clock_nanosleep (#21433) Fixes dotnet/android#6600 Backported from dotnet/runtime#64679 and dotnet/runtime#65373 (cherry picked from commit 36daf03) * Fix Windows build Co-authored-by: Simon Rozsival <simon@rozsival.com>
Fixes: dotnet#6600 Changes: mono/mono@148f536...f34bd77 * mono/mono@f34bd77e392: [2020-02][Android] Workaround for invalid return value from clock_nanosleep (#21435) * mono/mono@0f5e80e5770: Disable ClientWebSocketTest tests that started failing for no reason * mono/mono@4efc825e831: [Tools] Fix mono-api-html MarkdownFormatter.cs to avoid a NRE (#21431) * mono/mono@6171c871809: vtable setup fix for generic default interface methods in mono runtime (#21422)
"Easiest" way is to check the release notes…when I remember to actually write the release notes. (Doh. See also #5498, #5961, #6226…) Next easiest is to ask. :-) This fix should be included in Xamarin.Android 12.3, previews for which are included in Visual Studio 17.2. Ideally, #6780 will be merged and will be part of the forthcoming Visual Studio 17.2 Preview 2 release. We'll see what happens. |
Fixes: #6600 Changes: mono/mono@148f536...f34bd77 * mono/mono@f34bd77e392: [2020-02][Android] Workaround for invalid return value from clock_nanosleep (#21435) * mono/mono@0f5e80e5770: Disable ClientWebSocketTest tests that started failing for no reason * mono/mono@4efc825e831: [Tools] Fix mono-api-html MarkdownFormatter.cs to avoid a NRE (#21431) * mono/mono@6171c871809: vtable setup fix for generic default interface methods in mono runtime (#21422)
…k_nanosleep (#65372) * [Android] Workaround for invalid return value from clock_nanosleep (#64679) There used to be a bug in Android libc implementation of `clock_nanosleep`. The return value should be `errno` on errors but instead in it returns `-1` and sets `errno`. The libc (Bionic) bug [has been fixed](https://android-review.googlesource.com/c/platform/bionic/+/110652/) since Android 6 and newer but it causes problems to [customers who are unable to update Android on their devices](dotnet/android#6600 (comment)). Fixes dotnet/android#6600 * Account for incorrect implementation of clock_nanosleep in older Android libc * Shorten comments * Add g_clock_nanosleep function * Add remap definition * Fix build * Make sure the extra check runs only on Android * Make Windows builds happy * Try making wasm builds happy * Fix leftover direct call to clock_nanosleep
Hi every one, |
@truff77 FYI, Jon Pryor confirmed on Discord that this fix is in 17.2 Preview 2 |
@jfichtner @jonpryor thank you ! |
Android application type
Classic Xamarin.Android (MonoAndroid12.0, etc.)
Affected platform version
VS 16.4 (Xamarin.Android 10.1) and newer
Description
My team has been experiencing a crash very similar to #3892 for many, many months hoping for a fix to come along at some point in a new Xamarin.Android version, but unfortunately the issue still persists. My team develops "kiosk" apps (i.e. the only foreground app on the system, runs 24/7 for days, weeks, or months between reboots), that run on custom hardware, which currently runs an Android 4.4.3 based OS. We experience the crash somewhere between 0 and 4 days after starting the application, and it is very consistent in that timeframe. This issue seems to have been introduced in VS version 16.4, so our workaround has been to freeze the version of VS that we use to compile our production releases at version 16.3.10, which is now about 25 months old, and we cannot afford to continue using such an out of date version. It should be noted that Mono was update from v6.4 to v6.6 in VS v16.4, which adds about 800 commits according to the documentation. I assume the culprit lies in one of these commits.
The relevant error message is:
monoeg_g_usleep: clock_nanosleep () returned -1
This same error was reported by a commenter in issue #3892 by @jiro-san here, but no resolution was reported, and this particular error message does not appear in the original issue description/log.
Note that we observe this issue on our Android 4.4.3 based OS, but we have been testing a port of Android 7.1.1 that runs on our hardware, and we have found that this issue does NOT occur when running on this newer OS. Unfortunately there are other issues with this OS that prevent us from using this OS version in production, and we don't know if these issues will be resolved anytime soon. So this issue seems to be related to an interaction between MONO and the underlying OS. Perhaps it's related to the change from Dalvik to ART?
Steps to Reproduce
Unfortunately since this occurs on an app that runs on custom hardware, and relies on that hardware to run properly, I cannot provide a sample application. Note, however, that the issue seems to have been introduced in VS 2019 v16.4, as it does not occur when built with v16.3.10.
Did you find any workaround?
Building with VS v16.3.10 is our only workaround. Any APK built with any newer version, up to at least v16.10.1, which I am currently running, is guaranteed to crash within about 4 days with this particular error message.
Relevant log output
The text was updated successfully, but these errors were encountered: