"Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)" after debugger pauses and then continues on nested exception #14170
Description
This appears to have been introduced or revealed by one of the changes in 5ad371d...bf4e8d2. Maybe de14ec6? Was that commit expected to touch the exception tracing behavior for the mobile runtimes?
Steps to Reproduce
- Start debugging the attached test case either from Visual Studio or on the command line using
sdb. - Tap the Button button in the app.
- Once the debugger pauses on the exception, continue running the app from the debugger.
Current Behavior
With Xamarin.Android 9.3.0.14 (bf4e8d2ae19), the application process exits uncleanly due to a native segmentation fault in mono_handle_exception_internal().
Last line of the debug output shown in Visual Studio:
04-22 23:25:38.972 F/libc ( 3500): Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x20 in tid 3500 (ame.AndroidApp1), pid 3500 (ame.AndroidApp1)
Additional state from adb logcat output:
04-22 23:25:38.972 3500 3500 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x20 in tid 3500 (ame.AndroidApp1), pid 3500 (ame.AndroidApp1)
04-22 23:25:39.021 3541 3541 I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
04-22 23:25:39.022 935 935 I /system/bin/tombstoned: received crash request for pid 3500
04-22 23:25:39.023 3541 3541 I crash_dump64: performing dump of process 3500 (target tid = 3500)
04-22 23:25:39.030 3541 3541 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
04-22 23:25:39.030 3541 3541 F DEBUG : Build fingerprint: 'google/blueline/blueline:9/PQ2A.190205.001/5163636:user/release-keys'
04-22 23:25:39.030 3541 3541 F DEBUG : Revision: 'MP1.0'
04-22 23:25:39.030 3541 3541 F DEBUG : ABI: 'arm64'
04-22 23:25:39.030 3541 3541 F DEBUG : pid: 3500, tid: 3500, name: ame.AndroidApp1 >>> com.companyname.AndroidApp1 <<<
04-22 23:25:39.030 3541 3541 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x20
04-22 23:25:39.030 3541 3541 F DEBUG : Cause: null pointer dereference
04-22 23:25:39.030 3541 3541 F DEBUG : x0 0000000000000000 x1 0000000000000000 x2 0000000000000000 x3 0000007ff57e9d00
04-22 23:25:39.030 3541 3541 F DEBUG : x4 00000074dd3309a0 x5 0000007ff57e9d90 x6 0000000000000000 x7 0000000000000000
04-22 23:25:39.030 3541 3541 F DEBUG : x8 0000000000000000 x9 0000000000000000 x10 0000000000000000 x11 0000000000000000
04-22 23:25:39.030 3541 3541 F DEBUG : x12 0000000000000000 x13 0000000000000000 x14 00000000ffffffff x15 0000000000000187
04-22 23:25:39.030 3541 3541 F DEBUG : x16 00000074c60201f8 x17 00000074c5e48658 x18 0000000000000000 x19 00000074c6037560
04-22 23:25:39.030 3541 3541 F DEBUG : x20 0000000000000002 x21 0000000000000000 x22 0000000000000000 x23 000000000000007f
04-22 23:25:39.030 3541 3541 F DEBUG : x24 0000000000000000 x25 0000000000000000 x26 0000007ff57e9e80 x27 00000074c15b34a0
04-22 23:25:39.030 3541 3541 F DEBUG : x28 00000074dd330000 x29 0000007ff57e91a0
04-22 23:25:39.030 3541 3541 F DEBUG : sp 0000007ff57e91a0 lr 00000074c5d92640 pc 00000074c5e48660
04-22 23:25:39.030 3541 3541 F DEBUG :
04-22 23:25:39.030 3541 3541 F DEBUG : backtrace:
04-22 23:25:39.030 3541 3541 F DEBUG : #00 pc 0000000000173660 /data/app/Mono.Android.DebugRuntime-M4WLxJ5xl-4zk411sdgyvw==/lib/arm64/libmonosgen-64bit-2.0.so (mono_jit_info_get_method+8)
Excerpt of the top of backtrace from lldb at the time of the SIGSEGV, using the symbols from an un-stripped runtime:
* thread #1, name = 'ame.AndroidApp1', stop reason = breakpoint 1.1
* frame #0: 0x00000074dcd75da8 libart.so`art_sigsegv_fault
frame #1: 0x00000074dcd762b4 libart.so`art::FaultManager::HandleFault(int, siginfo*, void*) + 356
frame #2: 0x00000064a9d5cb5c app_process64`___lldb_unnamed_symbol20$$app_process64 + 572
frame #3: 0x0000007562c5b870 [vdso]
frame #4: 0x00000074c5d92640 libmonosgen-2.0.d.so`mono_handle_exception_internal [inlined] jinfo_get_method(ji=0x0000000000000000) at mini-runtime.h:390
frame #5: 0x00000074c5d92638 libmonosgen-2.0.d.so`mono_handle_exception_internal(ctx=<unavailable>, obj=<unavailable>, resume=0, out_ji=<unavailable>) at mini-exceptions.c:2701
frame #6: 0x00000074c5d92640 libmonosgen-2.0.d.so`mono_handle_exception_internal [inlined] jinfo_get_method(ji=0x00000074c13231b8) at mini-runtime.h:390
frame #7: 0x00000074c5d92638 libmonosgen-2.0.d.so`mono_handle_exception_internal(ctx=<unavailable>, obj=<unavailable>, resume=0, out_ji=<unavailable>) at mini-exceptions.c:2701
frame #8: 0x00000074c5d922b8 libmonosgen-2.0.d.so`mono_handle_exception(ctx=<unavailable>, obj=<unavailable>) at mini-exceptions.c:2988
frame #9: 0x00000074c5dca01c libmonosgen-2.0.d.so`mono_arm_throw_exception(arg=<unavailable>, pc=<unavailable>, int_regs=0x0000007ff57e9a60, fp_regs=0x0000007ff57e9b60, corlib=<unavailable>, rethrow=0) at exceptions-arm64.c:410
Expected Behavior
With Xamarin.Android 9.2.0.5 (5ad371dab1b), the application exits due to the unhandled managed exception itself rather than due to a native fault.
On which platforms did you notice this
[*] Android 9.0 (API level 28) arm64-v8a Google Pixel 3
[ ] macOS
[ ] Linux
[ ] Windows
I was not able to reproduce on:
- Android 7.1 (API level 25) x86 emulator
- Android 7.1 (API level 25) armeabi-v7a device
Version Used:
Xamarin.Android 9.3.0.14 (bf4e8d2ae19)