Skip to content
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

Closed
jfichtner opened this issue Jan 3, 2022 · 15 comments · Fixed by dotnet/runtime#64679, mono/mono#21433 or #6780
Assignees
Labels
Area: Mono Runtime Mono-related issues: BCL bugs, AOT issues, etc.

Comments

@jfichtner
Copy link

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

01-02 14:25:33.250: V/IncomingQueue(791): [ 01-02 14:25:33.260   791:  826 F/         ]
01-02 14:25:33.250: V/IncomingQueue(791): monoeg_g_usleep: clock_nanosleep () returned -1
01-02 14:25:33.260: A/libc(791): Fatal signal 6 (SIGABRT) at 0x00000317 (code=-6), thread 826 (iton.instrument)
01-02 14:25:33.340: D/dalvikvm(791): GC_EXPLICIT freed 628K, 30% free 9427K/13392K, paused 3ms+7ms, total 75ms
01-02 14:25:33.370: I/DEBUG(171): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-02 14:25:33.370: I/DEBUG(171): Build fingerprint: 'boundary/lakeshore/lakeshore:4.4.3/ls2.6.2_4.4.3_2.0.1-ga/ls2.6.2_20160816:user/dev-keys'
01-02 14:25:33.370: I/DEBUG(171): Revision: '397331'
01-02 14:25:33.370: I/DEBUG(171): pid: 791, tid: 826, name: iton.instrument  >>> com.lakeshore.xip.triton.instrument <<<
01-02 14:25:33.370: I/DEBUG(171): signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
01-02 14:25:33.490: I/DEBUG(171):     r0 00000000  r1 0000033a  r2 00000006  r3 00000000
01-02 14:25:33.490: I/DEBUG(171):     r4 00000006  r5 00000004  r6 0000033a  r7 0000010c
01-02 14:25:33.490: I/DEBUG(171):     r8 00000002  r9 ffffffff  sl 556c0188  fp 62504128
01-02 14:25:33.490: I/DEBUG(171):     ip 2b12e384  sp 625040c8  lr 2b0f30bd  pc 2b102088  cpsr 000f0010
01-02 14:25:33.490: I/DEBUG(171):     d0  0000000000000400  d1  0000000000000000
01-02 14:25:33.490: I/DEBUG(171):     d2  0000000000000000  d3  408ec00000000000
01-02 14:25:33.490: I/DEBUG(171):     d4  3fb999999999999a  d5  3fc35dcc60000000
01-02 14:25:33.490: I/DEBUG(171):     d6  4059000000000000  d7  40752a45ab7a6621
01-02 14:25:33.490: I/DEBUG(171):     d8  00000000c1b40000  d9  42900000c4ca8000
01-02 14:25:33.490: I/DEBUG(171):     d10 0000000000000000  d11 0000000000000000
01-02 14:25:33.490: I/DEBUG(171):     d12 0000000000000000  d13 0000000000000000
01-02 14:25:33.490: I/DEBUG(171):     d14 0000000000000000  d15 0000000000000000
01-02 14:25:33.490: I/DEBUG(171):     d16 3fed8f482c000000  d17 3fd287a7636f4361
01-02 14:25:33.490: I/DEBUG(171):     d18 3ff8000000000000  d19 0000000000000000
01-02 14:25:33.490: I/DEBUG(171):     d20 3fe62e42fefa39ef  d21 be205c610ca86c39
01-02 14:25:33.490: I/DEBUG(171):     d22 bf66c16c16bebd93  d23 3f50000000000000
01-02 14:25:33.490: I/DEBUG(171):     d24 8000000000000000  d25 3ff0000000000000
01-02 14:25:33.490: I/DEBUG(171):     d26 0000000000000000  d27 8000000000000000
01-02 14:25:33.490: I/DEBUG(171):     d28 8000000000000000  d29 0000000000000000
01-02 14:25:33.490: I/DEBUG(171):     d30 0000000000000000  d31 3f11566aaf25de2c
01-02 14:25:33.490: I/DEBUG(171):     scr 80000011
01-02 14:25:33.490: I/DEBUG(171): backtrace:
01-02 14:25:33.490: I/DEBUG(171):     #00  pc 00022088  /system/lib/libc.so (tgkill+12)
01-02 14:25:33.490: I/DEBUG(171):     #01  pc 000130b9  /system/lib/libc.so (pthread_kill+48)
01-02 14:25:33.490: I/DEBUG(171):     #02  pc 000132cd  /system/lib/libc.so (raise+10)
01-02 14:25:33.490: I/DEBUG(171):     #03  pc 00012003  /system/lib/libc.so
01-02 14:25:33.490: I/DEBUG(171):     #04  pc 0002193c  /system/lib/libc.so (abort+4)
01-02 14:25:33.490: I/DEBUG(171):     #05  pc 002e4978  /data/app-lib/com.lakeshore.xip.triton.instrument-2/libmonosgen-2.0.so (monoeg_assert_abort+28)
01-02 14:25:33.490: I/DEBUG(171): stack:
01-02 14:25:33.490: I/DEBUG(171):          62504088  65f62508  [anon:libc_malloc]
01-02 14:25:33.490: I/DEBUG(171):          6250408c  2b0f191f  /system/lib/libc.so (dlrealloc+122)
01-02 14:25:33.490: I/DEBUG(171):          62504090  2b0f18a5  /system/lib/libc.so (dlrealloc)
01-02 14:25:33.500: I/DEBUG(171):          62504094  0000002f  
01-02 14:25:33.500: I/DEBUG(171):          62504098  00000000  
01-02 14:25:33.500: I/DEBUG(171):          6250409c  62504134  [stack:826]
01-02 14:25:33.500: I/DEBUG(171):          625040a0  55613ec1  /data/app-lib/com.lakeshore.xip.triton.instrument-2/libmonosgen-2.0.so
01-02 14:25:33.500: I/DEBUG(171):          625040a4  2b0edd0d  /system/lib/libc.so (realloc+12)
01-02 14:25:33.500: I/DEBUG(171):          625040a8  00000030  
01-02 14:25:33.500: I/DEBUG(171):          625040ac  2b106b49  /system/lib/libc.so (vasprintf+88)
01-02 14:25:33.500: I/DEBUG(171):          625040b0  2b0dc0b1  /system/lib/liblog.so
01-02 14:25:33.500: I/DEBUG(171):          625040b4  2b0dd5f9  /system/lib/liblog.so
01-02 14:25:33.500: I/DEBUG(171):          625040b8  65f62508  [anon:libc_malloc]
01-02 14:25:33.500: I/DEBUG(171):          625040bc  00000000  
01-02 14:25:33.500: I/DEBUG(171):          625040c0  e3a070ad  
01-02 14:25:33.500: I/DEBUG(171):          625040c4  ef9000ad  
01-02 14:25:33.500: I/DEBUG(171):     #00  625040c8  00000006  
01-02 14:25:33.500: I/DEBUG(171):          625040cc  00000004  
01-02 14:25:33.500: I/DEBUG(171):          625040d0  0000033a  
01-02 14:25:33.500: I/DEBUG(171):          625040d4  2b12e384  
01-02 14:25:33.500: I/DEBUG(171):          625040d8  2b12e384  
01-02 14:25:33.500: I/DEBUG(171):          625040dc  2b0f30bd  /system/lib/libc.so (pthread_kill+52)
01-02 14:25:33.500: I/DEBUG(171):     #01  625040e0  00000006  
01-02 14:25:33.500: I/DEBUG(171):          625040e4  00000000  
01-02 14:25:33.500: I/DEBUG(171):          625040e8  555d64ac  /data/app-lib/com.lakeshore.xip.triton.instrument-2/libmonosgen-2.0.so
01-02 14:25:33.500: I/DEBUG(171):          625040ec  2b0f32d1  /system/lib/libc.so (raise+14)
01-02 14:25:33.500: I/DEBUG(171):     #02  625040f0  625040fc  [stack:826]
01-02 14:25:33.500: I/DEBUG(171):          625040f4  2b0f2007  /system/lib/libc.so
01-02 14:25:33.500: I/DEBUG(171): memory near sl:
01-02 14:25:33.500: I/DEBUG(171):     556c0168 00000000 00000000 00000000 00000000  
01-02 14:25:33.500: I/DEBUG(171):     556c0178 00000000 00000000 00000000 000003f0  
01-02 14:25:33.500: I/DEBUG(171):     556c0188 00000002 66070760 00000000 00000002  
01-02 14:25:33.500: I/DEBUG(171):     556c0198 66070750 00000000 00000002 66070740  
01-02 14:25:33.500: I/DEBUG(171):     556c01a8 00000000 00000002 66070730 00000000  
01-02 14:25:33.500: I/DEBUG(171):     556c01b8 00000002 66070720 00000000 00000002  
01-02 14:25:33.500: I/DEBUG(171):     556c01c8 66070710 00000000 00000002 66070700  
01-02 14:25:33.500: I/DEBUG(171):     556c01d8 00000000 00000002 660706f0 00000000  
01-02 14:25:33.500: I/DEBUG(171):     556c01e8 00000002 660706e0 00000000 00000002  
01-02 14:25:33.500: I/DEBUG(171):     556c01f8 660706d0 00000000 00000002 660706c0  
01-02 14:25:33.500: I/DEBUG(171):     556c0208 00000000 00000002 660706b0 00000000  
01-02 14:25:33.500: I/DEBUG(171):     556c0218 00000002 660706a0 00000000 00000002  
01-02 14:25:33.500: I/DEBUG(171):     556c0228 66070690 00000000 00000002 66070680  
01-02 14:25:33.500: I/DEBUG(171):     556c0238 00000000 00000002 66070670 00000000  
01-02 14:25:33.500: I/DEBUG(171):     556c0248 00000002 66070660 00000000 00000002  
01-02 14:25:33.500: I/DEBUG(171):     556c0258 66070650 00000000 00000002 66070640  
01-02 14:25:33.500: I/DEBUG(171): memory near fp:
01-02 14:25:33.500: I/DEBUG(171):     62504108 00000000 a894cea7 573ff348 00000004  
01-02 14:25:33.500: I/DEBUG(171):     62504118 00000000 2b101940 2b0dc0b1 555f397c  
01-02 14:25:33.500: I/DEBUG(171):     62504128 62504550 555f3c30 621b9320 65f62508  
01-02 14:25:33.500: I/DEBUG(171):     62504138 00000000 56d8af20 62304220 622fb7f0  
01-02 14:25:33.500: I/DEBUG(171):     62504148 00000000 62504140 56d8af14 00000000  
01-02 14:25:33.500: I/DEBUG(171):     62504158 00000000 00000000 00000000 00000004  
01-02 14:25:33.500: I/DEBUG(171):     62504168 573fadd8 573ff33c 6221007d 6270486c  
01-02 14:25:33.500: I/DEBUG(171):     62504178 00000004 58c4c248 573fae68 573fadd8  
01-02 14:25:33.500: I/DEBUG(171):     62504188 573ff348 56da8220 56e18180 00000000  
01-02 14:25:33.500: I/DEBUG(171):     62504198 62504184 00000000 000007bc 00000000  
01-02 14:25:33.500: I/DEBUG(171):     625041a8 00000006 573fadd8 56e0f0c8 6269e118  
01-02 14:25:33.500: I/DEBUG(171):     625041b8 625041c0 626bc598 56e0f0c8 56e18180  
01-02 14:25:33.500: I/DEBUG(171):     625041c8 625042d0 6270230c 62fa0780 62504570  
01-02 14:25:33.500: I/DEBUG(171):     625041d8 62504588 00000000 00000109 00000002  
01-02 14:25:33.500: I/DEBUG(171):     625041e8 ffffffff 556c0188 62504580 2b0c88b8  
01-02 14:25:33.500: I/DEBUG(171):     625041f8 0000001e 00000000 fffffffa 00000317  
01-02 14:25:33.500: I/DEBUG(171): memory near ip:
01-02 14:25:33.500: I/DEBUG(171):     2b12e364 00001000 00001000 00010000 00200000  
01-02 14:25:33.500: I/DEBUG(171):     2b12e374 00000003 2b105a8d 7e96e950 7e96e9fc  
01-02 14:25:33.500: I/DEBUG(171):     2b12e384 a894cea7 51493718 00000000 2b0cacf0  
01-02 14:25:33.500: I/DEBUG(171):     2b12e394 00000007 00000008 65883340 00000000  
01-02 14:25:33.500: I/DEBUG(171):     2b12e3a4 2c9e7000 00000009 0000000a 00000002  
01-02 14:25:33.500: I/DEBUG(171):     2b12e3b4 00000010 00000000 00000000 00000000  
01-02 14:25:33.500: I/DEBUG(171):     2b12e3c4 00000000 00000000 00000000 00000000  
01-02 14:25:33.500: I/DEBUG(171):     2b12e3d4 00000000 00000000 00000000 00000000  
01-02 14:25:33.500: I/DEBUG(171):     2b12e3e4 00000000 00000000 00000000 00000000  
01-02 14:25:33.500: I/DEBUG(171):     2b12e3f4 00000000 00000000 00000000 00000000  
01-02 14:25:33.500: I/DEBUG(171):     2b12e404 00000000 00000000 00000000 00000000  
01-02 14:25:33.500: I/DEBUG(171):     2b12e414 00000000 00000000 00000000 00000000  
01-02 14:25:33.500: I/DEBUG(171):     2b12e424 00000000 00000000 00000000 00000000  
01-02 14:25:33.500: I/DEBUG(171):     2b12e434 00000000 00000000 00000000 00000000  
01-02 14:25:33.500: I/DEBUG(171):     2b12e444 00000000 00000000 00000000 00000000  
01-02 14:25:33.500: I/DEBUG(171):     2b12e454 00000000 00000000 00000000 00000000  
01-02 14:25:33.500: I/DEBUG(171): memory near sp:
01-02 14:25:33.500: I/DEBUG(171):     625040a8 00000030 2b106b49 2b0dc0b1 2b0dd5f9  
01-02 14:25:33.500: I/DEBUG(171):     625040b8 65f62508 00000000 e3a070ad ef9000ad  
01-02 14:25:33.500: I/DEBUG(171):     625040c8 00000006 00000004 0000033a 2b12e384  
01-02 14:25:33.500: I/DEBUG(171):     625040d8 2b12e384 2b0f30bd 00000006 00000000  
01-02 14:25:33.500: I/DEBUG(171):     625040e8 555d64ac 2b0f32d1 625040fc 2b0f2007  
01-02 14:25:33.500: I/DEBUG(171):     625040f8 62302958 ffffffdf 00000007 5538629c  
01-02 14:25:33.500: I/DEBUG(171):     62504108 00000000 a894cea7 573ff348 00000004  
01-02 14:25:33.500: I/DEBUG(171):     62504118 00000000 2b101940 2b0dc0b1 555f397c  
01-02 14:25:33.500: I/DEBUG(171):     62504128 62504550 555f3c30 621b9320 65f62508  
01-02 14:25:33.500: I/DEBUG(171):     62504138 00000000 56d8af20 62304220 622fb7f0  
01-02 14:25:33.500: I/DEBUG(171):     62504148 00000000 62504140 56d8af14 00000000  
01-02 14:25:33.500: I/DEBUG(171):     62504158 00000000 00000000 00000000 00000004  
01-02 14:25:33.500: I/DEBUG(171):     62504168 573fadd8 573ff33c 6221007d 6270486c  
01-02 14:25:33.500: I/DEBUG(171):     62504178 00000004 58c4c248 573fae68 573fadd8  
01-02 14:25:33.500: I/DEBUG(171):     62504188 573ff348 56da8220 56e18180 00000000  
01-02 14:25:33.500: I/DEBUG(171):     62504198 62504184 00000000 000007bc 00000000  
01-02 14:25:33.500: I/DEBUG(171): code around pc:
01-02 14:25:33.500: I/DEBUG(171):     2b102068 e8bd00f0 e3700a01 912fff1e e2600000  
01-02 14:25:33.500: I/DEBUG(171):     2b102078 ea006f07 e92d50f0 e3a07f43 ef000000  
01-02 14:25:33.500: I/DEBUG(171):     2b102088 e8bd50f0 e3700a01 912fff1e e2600000  
01-02 14:25:33.500: I/DEBUG(171):     2b102098 ea006eff e92d50f0 e3a070ee ef000000  
01-02 14:25:33.500: I/DEBUG(171):     2b1020a8 e8bd50f0 e3700a01 912fff1e e2600000  
01-02 14:25:33.500: I/DEBUG(171):     2b1020b8 ea006ef7 e1520003 8a006efd e92d4011  
01-02 14:25:33.500: I/DEBUG(171):     2b1020c8 e24dd01c f5d0f000 f5d1f000 f5d1f020  
01-02 14:25:33.500: I/DEBUG(171):     2b1020d8 e3520004 3a0000b7 e2613000 e2133003  
01-02 14:25:33.500: I/DEBUG(171):     2b1020e8 0a000007 e1b0cf83 e0422003 44d13001  
01-02 14:25:33.500: I/DEBUG(171):     2b1020f8 24d14001 24d1c001 44c03001 24c04001  
01-02 14:25:33.500: I/DEBUG(171):     2b102108 24c0c001 e020c001 e31c0003 1a00002b  
01-02 14:25:33.500: I/DEBUG(171):     2b102118 e88d0fe0 e2603000 e213301c 0a00000a  
01-02 14:25:33.500: I/DEBUG(171):     2b102128 e1530002 8202301c e1b0ce03 28b100f0  
01-02 14:25:33.500: I/DEBUG(171):     2b102138 48b10300 28a000f0 48a00300 e3130004  
01-02 14:25:33.500: I/DEBUG(171):     2b102148 1491a004 1480a004 e0422003 e2522020  
01-02 14:25:33.500: I/DEBUG(171):     2b102158 3a000008 e3c1c01f e28cc040 e8b10ff0  
01-02 14:25:33.500: I/DEBUG(171): code around lr:
01-02 14:25:33.510: I/DEBUG(171):     2b0f309c 447b4b13 42b3e010 6a1ed10e 44784811  
01-02 14:25:33.510: I/DEBUG(171):     2b0f30ac ec84f7fb ea0ef00d 46224631 efe0f00e  
01-02 14:25:33.510: I/DEBUG(171):     2b0f30bc d00a3001 e00b2400 2b00681b 480ad1eb  
01-02 14:25:33.510: I/DEBUG(171):     2b0f30cc 44782403 ec72f7fb f001e002 6804fa23  
01-02 14:25:33.510: I/DEBUG(171):     2b0f30dc fa20f001 46206005 bf00bd70 0003b306  
01-02 14:25:33.510: I/DEBUG(171):     2b0f30ec 0003b2fa 0003b2f2 0003b2ce bf7ef7ff  
01-02 14:25:33.510: I/DEBUG(171):     2b0f30fc 4a3e4b3d e92d447b b08b43f0 4606589c  
01-02 14:25:33.510: I/DEBUG(171):     2b0f310c 6823460d 930946a1 fa04f001 8000f8d0  
01-02 14:25:33.510: I/DEBUG(171):     2b0f311c d0482d00 f0104628 280ff82d d8444604  
01-02 14:25:33.510: I/DEBUG(171):     2b0f312c ffe4f7ff d1064286 4629200f e8d8f00d  
01-02 14:25:33.510: I/DEBUG(171):     2b0f313c d03c2800 482ee02e f7fb4478 482debb6  
01-02 14:25:33.510: I/DEBUG(171):     2b0f314c e0154478 d11342b0 482b6a06 f7fb4478  
01-02 14:25:33.510: I/DEBUG(171):     2b0f315c 4a2aec2e 46332120 a801447a fb4ef013  
01-02 14:25:33.510: I/DEBUG(171):     2b0f316c a8012101 fe68f01a 46061c42 e011d104  
01-02 14:25:33.510: I/DEBUG(171):     2b0f317c 28006800 e02cd1e6 46294630 f00d4622  
01-02 14:25:33.510: I/DEBUG(171):     2b0f318c 1c43e914 d11e4607 f9c4f001 29046801  
01-02 14:25:33.740: W/ActivityManager(470):   Force finishing activity com.lakeshore.xip.triton.instrument/crc64941d6d01744d5c82.MainActivity
01-02 14:25:33.740: I/BootReceiver(470): Copying /data/tombstones/tombstone_01 to DropBox (SYSTEM_TOMBSTONE)
01-02 14:25:33.790: D/dalvikvm(470): GC_CONCURRENT freed 330K, 14% free 5148K/5952K, paused 3ms+3ms, total 48ms
01-02 14:25:33.790: D/dalvikvm(470): WAIT_FOR_CONCURRENT_GC blocked 36ms
01-02 14:25:33.820: W/InputDispatcher(470): channel '2cde5240 com.lakeshore.xip.triton.instrument/com.lakeshore.xip.SplashActivity (server)' ~ Consumer closed input channel or an error occurred.  events=0x9
01-02 14:25:33.820: E/InputDispatcher(470): channel '2cde5240 com.lakeshore.xip.triton.instrument/com.lakeshore.xip.SplashActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
01-02 14:25:33.820: D/dalvikvm(470): GC_FOR_ALLOC freed 14K, 12% free 5262K/5952K, paused 26ms, total 26ms
01-02 14:25:33.820: I/dalvikvm-heap(470): Grow heap (frag case) to 5.396MB for 196628-byte allocation
01-02 14:25:33.830: W/InputDispatcher(470): channel '2ce35360 com.lakeshore.xip.triton.instrument/crc64941d6d01744d5c82.MainActivity (server)' ~ Consumer closed input channel or an error occurred.  events=0x9
01-02 14:25:33.830: E/InputDispatcher(470): channel '2ce35360 com.lakeshore.xip.triton.instrument/crc64941d6d01744d5c82.MainActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
01-02 14:25:33.840: D/Zygote(173): Process 791 terminated by signal (6)
01-02 14:25:33.850: D/dalvikvm(470): GC_FOR_ALLOC freed 128K, 14% free 5326K/6148K, paused 27ms, total 27ms
01-02 14:25:33.850: D/dalvikvm(470): WAIT_FOR_CONCURRENT_GC blocked 75ms
01-02 14:25:33.850: W/InputDispatcher(470): Attempted to unregister already unregistered input channel '2ce35360 com.lakeshore.xip.triton.instrument/crc64941d6d01744d5c82.MainActivity (server)'
01-02 14:25:33.850: W/InputDispatcher(470): Attempted to unregister already unregistered input channel '2cde5240 com.lakeshore.xip.triton.instrument/com.lakeshore.xip.SplashActivity (server)'
01-02 14:25:33.850: I/WindowState(470): WIN DEATH: Window{2ce35360 u0 com.lakeshore.xip.triton.instrument/crc64941d6d01744d5c82.MainActivity}
01-02 14:25:33.850: I/WindowState(470): WIN DEATH: Window{2cde5240 u0 com.lakeshore.xip.triton.instrument/com.lakeshore.xip.SplashActivity}
01-02 14:25:33.880: D/dalvikvm(470): GC_FOR_ALLOC freed 403K, 18% free 5098K/6148K, paused 25ms, total 25ms
@jfichtner jfichtner added Area: App Runtime Issues in `libmonodroid.so`. needs-triage Issues that need to be assigned. labels Jan 3, 2022
@grendello
Copy link
Contributor

It appears to be an issue with the Linux kernel on the version of Android you're using. The clock_nanosleep call should never return -1, it should return 0 for success or a positive error code (the kernel actually returns the same error code negated) but none of the errno error codes have the value of 1, so in theory a return of -1 one is impossible, but here we are. I don't think there any way for us to fix it, but this code in Mono (and a similar one here) could be improved to fall back to the code path that doesn't use clock_nanosleep should the syscall return any error. @lambdageek, do you think it would make sense?

@grendello grendello assigned lambdageek and unassigned grendello Jan 3, 2022
@grendello grendello added Area: Mono Runtime Mono-related issues: BCL bugs, AOT issues, etc. and removed Area: App Runtime Issues in `libmonodroid.so`. needs-triage Issues that need to be assigned. labels Jan 3, 2022
@lambdageek
Copy link
Member

do you think it would make sense?

Yea makes sense to me. @steveisok maybe someone from your team can make the change. I can help out.

@truff77
Copy link

truff77 commented Jan 27, 2022

Hi all,

I've been experiencing the same issue related to clock_nanosleep() returning -1. I've done some investigations:

  • in the kernel: the clock_nanosleep syscall will return negative values
  • in the Android libc(Bionic) and this is where things look like to be interesting:

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.
There are then 2 solutions:

  • you conform to the Bionic libc usage of clock_nanosleep()
  • Bionic libc fixes error management for clock_nanosleep() to be POSIX compliant

Hope this helps !

@steveisok steveisok assigned steveisok and unassigned lambdageek Jan 27, 2022
@steveisok
Copy link
Member

For some reason I can't assign @simonrozsival, but he's going to take on fixing this.

@lambdageek lambdageek assigned steveisok and unassigned steveisok Jan 27, 2022
@simonrozsival
Copy link
Member

The failure behavior of clock_nanosleep was fixed here: https://android-review.googlesource.com/c/platform/bionic/+/110652/ and it has been shipping since Android 6.0.

@jfichtner
Copy link
Author

@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?

@truff77
Copy link

truff77 commented Jan 31, 2022

Hi @simonrozsival & all,
You are right, I opened a case at Google/Android and a dev replied with the patch they did back in 2014 ...
We are using Android 5.1 and think it is time to move to a more recent version.

@simonrozsival
Copy link
Member

@jfichtner I see. I'll open a PR which will handle the -1 return value later this week.

lambdageek pushed a commit to dotnet/runtime that referenced this issue Feb 9, 2022
…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
@jfichtner
Copy link
Author

@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!

@jiro-san
Copy link

jiro-san commented Feb 9, 2022

@simonrozsival and @lambdageek thank you very much this will be huge also for us, we might finally be able to upgrade our build environment!

simonrozsival added a commit to simonrozsival/runtime that referenced this issue Feb 15, 2022
…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
@jfichtner
Copy link
Author

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.

akoeplinger pushed a commit to akoeplinger/mono that referenced this issue Feb 17, 2022
akoeplinger added a commit to mono/mono that referenced this issue Feb 17, 2022
…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>
jonpryor added a commit to jonpryor/xamarin-android that referenced this issue Feb 18, 2022
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)
@jonpryor
Copy link
Member

@jfichtner asked:

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?

"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. :-)
…probably on Discord, on the #android channel.

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.

jonpryor added a commit that referenced this issue Feb 20, 2022
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)
lewing pushed a commit to dotnet/runtime that referenced this issue Mar 10, 2022
…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
@truff77
Copy link

truff77 commented Mar 22, 2022

Hi every one,
I just saw that visual studio 17.2 Preview 2 has been released. I can't see in the Changelog any information related to Xamarin update. Can someone confirm that this fix is included please ?
Thanks in advance !

@jfichtner
Copy link
Author

@truff77 FYI, Jon Pryor confirmed on Discord that this fix is in 17.2 Preview 2

@truff77
Copy link

truff77 commented Mar 25, 2022

@jfichtner @jonpryor thank you !

@ghost ghost locked as resolved and limited conversation to collaborators Jun 2, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.