Bug 18763 - Native SIGSEGVs don't invoke Android's SIGSEGV handler
Summary: Native SIGSEGVs don't invoke Android's SIGSEGV handler
Status: VERIFIED FIXED
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler ()
Version: 4.13.x
Hardware: PC Mac OS
: Normal enhancement
Target Milestone: 5.1
Assignee: Marek Habersack
URL:
Depends on:
Blocks:
 
Reported: 2014-04-02 15:13 UTC by Jonathan Pryor
Modified: 2015-05-05 13:08 UTC (History)
5 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Scratch.Sigsegv.zip (12.95 KB, application/zip)
2014-04-02 15:13 UTC, Jonathan Pryor
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:
Status:
VERIFIED FIXED

Description Jonathan Pryor 2014-04-02 15:13:19 UTC
Created attachment 6466 [details]
Scratch.Sigsegv.zip

Consider the attached Scratch.Sigsegv.zip project, a Xamarin.Android app which invokes libdie.so!kill_the_host(), which triggers a SIGSEGV from native code:

    int *p = 0;
    *p = 0;

At present (Xamarin.Android <= 4.12.3), Mono's SIGSEGV handler is invoked, which prints the managed stack trace:

> E/mono-rt (30010): Stacktrace:
> E/mono-rt (30010): 
> E/mono-rt (30010):   at <unknown> <0xffffffff>
> E/mono-rt (30010):   at (wrapper managed-to-native) Scratch.Sigsegv.MainActivity.kill_the_host () <0xffffffff>
> E/mono-rt (30010):   at Scratch.Sigsegv.MainActivity.OnCreate (Android.OS.Bundle) <0x00053>
> E/mono-rt (30010):   at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_ (intptr,intptr,intptr) <0x0005b>
> E/mono-rt (30010):   at (wrapper dynamic-method) object.a46db0a4-8d19-449e-beac-614ef2e53e6a (intptr,intptr,intptr) <0x00043>
> E/mono-rt (30010):   at (wrapper native-to-managed) object.a46db0a4-8d19-449e-beac-614ef2e53e6a (intptr,intptr,intptr) <0xffffffff>
> E/mono-rt (30010): 
> E/mono-rt (30010): =================================================================
> E/mono-rt (30010): Got a SIGSEGV while executing native code. This usually indicates
> E/mono-rt (30010): a fatal error in the mono runtime or one of the native libraries 
> E/mono-rt (30010): used by your application.
> E/mono-rt (30010): =================================================================
> E/mono-rt (30010): 

What _isn't_ printed is the "normal" Android SIGSEGV handler output, which would show e.g.

> F/libc    (30349): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 30349 (Scratch.Sigsegv)
> I/DEBUG   (  179): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
> I/DEBUG   (  179): Build fingerprint: 'google/hammerhead/hammerhead:4.4.2/KOT49H/937116:user/release-keys'
> I/DEBUG   (  179): Revision: '11'
> I/DEBUG   (  179): pid: 30349, tid: 30349, name: Scratch.Sigsegv  >>> Scratch.Sigsegv <<<
> I/DEBUG   (  179): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
> I/DEBUG   (  179):     r0 4c775b50  r1 bed39e40  r2 fffffd70  r3 00000000
> I/DEBUG   (  179): ...
> I/DEBUG   (  179): 
> I/DEBUG   (  179): backtrace:
> I/DEBUG   (  179):     #00  pc 00000ba6  /data/app-lib/Scratch.Sigsegv-1/libdie.so (kill_the_host+1)
> I/DEBUG   (  179):     #01  pc 000309d4  <unknown>
> I/DEBUG   (  179): 
> I/DEBUG   (  179): stack:
> I/DEBUG   (  179):          bed39e00  00000389  
> I/DEBUG   (  179):          bed39e04  65551528  /dev/ashmem/dalvik-alloc space (deleted)
> I/DEBUG   (  179):          bed39e08  4c7653c0  
> I/DEBUG   (  179):          bed39e0c  bed39e40  [stack]
> I/DEBUG   (  179):          bed39e10  4d518840  [anon:libc_malloc]
> I/DEBUG   (  179):          bed39e14  4d72f094  
> I/DEBUG   (  179):          bed39e18  655505b8  /dev/ashmem/dalvik-alloc space (deleted)
> I/DEBUG   (  179):          bed39e1c  4d5af7e8  [anon:libc_malloc]
> I/DEBUG   (  179):          bed39e20  416bbaf0  [anon:libc_malloc]
> I/DEBUG   (  179):          bed39e24  65551528  /dev/ashmem/dalvik-alloc space (deleted)
> I/DEBUG   (  179):          bed39e28  bed39f58  [stack]
> I/DEBUG   (  179):          bed39e2c  483412d8  /data/app-lib/Mono.Android.DebugRuntime-1/libmonosgen-2.0.so (mono_magic_trampoline+48)
> I/DEBUG   (  179):          bed39e30  00000000  
> I/DEBUG   (  179):          bed39e34  bed39e40  [stack]
> I/DEBUG   (  179):          bed39e38  e3a070ad  
> I/DEBUG   (  179):          bed39e3c  ef9000ad  
> I/DEBUG   (  179):     #00  bed39e40  4c775fc0  [anon:libc_malloc]
> I/DEBUG   (  179): ...

It would be useful if _both_ SIGSEGV messages were displayed when a native SIGSEGV occurs.
Comment 1 Jonathan Pryor 2014-04-02 15:15:00 UTC
In theory, mono_set_signal_chaining() can be used so that the Android SIGSEGV handler will be executed. The problem is that Mono's SIGSEGV handler _won't_ be invoked, meaning there's no way to obtain the managed stack trace, which is undesirable/useless.
Comment 3 Rodrigo Kumpera 2014-04-02 18:58:44 UTC
We could extend the runtime interface with the following: https://gist.github.com/9944950


This would let monodroid tell the runtime to special case crashes.

When crashing we don't abort after dumping crash info, instead we signal chain .
Comment 4 Jonathan Pryor 2014-05-14 09:09:01 UTC
Fixed in monodroid/bd2f31af.
Comment 5 Peter Collins 2014-06-10 17:01:26 UTC
I'm still not seeing the expected android SIGSEGV output from this project on master and 4.14-series,
here's a few gists of logcat output:

https://gist.github.com/pjcollins/a912256cc42cd08baf66
https://gist.github.com/pjcollins/74401099042cd91e9a68

Environment:
XA master / 8885b820
Dell Venue 8 3830 v4.3 (x86)
Samsung Galaxy S5 v 4.4.2
Comment 6 Jonathan Pryor 2014-06-20 11:26:58 UTC
Does this still fail for you? I've been reliably seeing the I/DEBUG messages.
Comment 7 Peter Collins 2014-06-20 11:46:44 UTC
As far as the particular test project attached here is concerned, I am still not seeing I/DEBUG messages. I ran this against XA 4.14-series / d37c1629

https://gist.github.com/pjcollins/d58f5c7634e1352a5d53
Comment 8 Saurabh 2014-07-08 06:16:52 UTC
I have checked this issue with following builds:

X.S 5.2 (Build 364)
Git revision: fd8641a35ed89a183d04290f046a3aab5b09a867
X.Android 4.14.0-46

I am getting I/DEBUG output in Android logcat as mentioned in this issue. This is the gist of android logcat: https://gist.github.com/saurabh360/a9d2503243018dd02544

Hence, closing this Issue
Comment 9 Peter Collins 2014-08-07 17:48:32 UTC
@Jonp I'm still having an issue getting the proper SIGSEGV output with the attached sample in my automated case. A simple xbuild /t:Install and /t:_Run do not seem to be substantial.

I am seeing the full output when deploying directly from Xamarin Studio, any idea what the difference might be here, do I need to set a logging variable or something of the sort?

Here's the diff between command line install and run vs XS debugging:
https://gist.github.com/pjcollins/fae167096a59bddbf68d
Comment 10 Jonathan Pryor 2014-08-12 15:29:33 UTC
> I'm still having an issue getting the proper SIGSEGV output 

By any chance, after running Scratch.Sigsegv does `adb logcat` contain something similar to:

> F/libc    (25765): Unable to open connection to debuggerd: Connection refused

That's what I'm saying, and partially describes why you aren't getting I/DEBUG messages: it's because debuggerd is never being invoked to generate them.

Unfortunately, I don't know how to "fix" the above F/libc message. :-(
Comment 11 Peter Collins 2014-08-12 15:33:16 UTC
Yeah I am also seeing the following in the case where I only Install and Run from command line:

> F/libc    (22504): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 22504 (Scratch.Sigsegv)
> F/libc    (22504): Unable to open connection to debuggerd: Connection refused
Comment 12 Jonathan Pryor 2014-08-12 15:41:23 UTC
Comment #10 aside, there is a problem with our current attempt at fixing this:

https://github.com/mono/mono/blob/303e42b1/mono/mini/mini.c#L6868

mono_handle_native_sigsegv() is assuming that on SIGSEGV, the "native"/"chained to" SIGSEGV handler will actually, you know, abort the process.

That appeared to be the case when debuggerd is involved.

That appears to NOT be the case when debuggerd is NOT involved, as I now see *two* abort messages!

> E/mono-rt ( 2739): Stacktrace:
> E/mono-rt ( 2739): 
> E/mono-rt ( 2739):   at <unknown> <0xffffffff>
> E/mono-rt ( 2739):   at (wrapper managed-to-native) Scratch.Sigsegv.MainActivity.kill_the_host () <0xffffffff>
> E/mono-rt ( 2739):   at Scratch.Sigsegv.MainActivity.OnCreate (Android.OS.Bundle) <0x00053>
> E/mono-rt ( 2739):   at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_ (intptr,intptr,intptr) <0x0005b>
> E/mono-rt ( 2739):   at (wrapper dynamic-method) object.a2f7c5cf-b4df-492b-a832-b5bbdc6b9aab (intptr,intptr,intptr) <0x00043>
> E/mono-rt ( 2739):   at (wrapper native-to-managed) object.a2f7c5cf-b4df-492b-a832-b5bbdc6b9aab (intptr,intptr,intptr) <0xffffffff>
> E/mono-rt ( 2739): 
> E/mono-rt ( 2739): =================================================================
> E/mono-rt ( 2739): Got a SIGSEGV while executing native code. This usually indicates
> E/mono-rt ( 2739): a fatal error in the mono runtime or one of the native libraries 
> E/mono-rt ( 2739): used by your application.
> E/mono-rt ( 2739): =================================================================
> E/mono-rt ( 2739): 
> F/libc    ( 2739): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 2739 (Scratch.Sigsegv)
> F/libc    ( 2739): Unable to open connection to debuggerd: Connection refused
> I/MonoDroid( 2739): UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object
> I/MonoDroid( 2739): at (wrapper managed-to-native) Scratch.Sigsegv.MainActivity.kill_the_host () <0x00033>
> I/MonoDroid( 2739): at Scratch.Sigsegv.MainActivity.OnCreate (Android.OS.Bundle) <0x00053>
> I/MonoDroid( 2739): at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_ (intptr,intptr,intptr) <0x0005b>
> I/MonoDroid( 2739): at (wrapper dynamic-method) object.a2f7c5cf-b4df-492b-a832-b5bbdc6b9aab (intptr,intptr,intptr) <0x00043>
> E/mono    ( 2739): 
> E/mono    ( 2739): Unhandled Exception:
> E/mono    ( 2739): System.NullReferenceException: Object reference not set to an instance of an object
> E/mono    ( 2739):   at (wrapper managed-to-native) Scratch.Sigsegv.MainActivity:kill_the_host ()
> E/mono    ( 2739):   at Scratch.Sigsegv.MainActivity.OnCreate (Android.OS.Bundle bundle) [0x00000] in <filename unknown>:0 
> E/mono    ( 2739):   at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_ (IntPtr jnienv, IntPtr native__this, IntPtr native_savedInstanceState) [0x00000] in <filename unknown>:0 
> E/mono    ( 2739):   at (wrapper dynamic-method) object:a2f7c5cf-b4df-492b-a832-b5bbdc6b9aab (intptr,intptr,intptr)
> E/mono-rt ( 2739): [ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object
> E/mono-rt ( 2739):   at (wrapper managed-to-native) Scratch.Sigsegv.MainActivity:kill_the_host ()
> E/mono-rt ( 2739):   at Scratch.Sigsegv.MainActivity.OnCreate (Android.OS.Bundle bundle) [0x00000] in <filename unknown>:0 
> E/mono-rt ( 2739):   at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_ (IntPtr jnienv, IntPtr native__this, IntPtr native_savedInstanceState) [0x00000] in <filename unknown>:0 
> E/mono-rt ( 2739):   at (wrapper dynamic-method) object:a2f7c5cf-b4df-492b-a832-b5bbdc6b9aab (intptr,intptr,intptr)

Actually, having run Scratch.Sigsegv multiple times, I don't always get the "Unable to open connection to debuggerd" message. Even when I don't see the F/libc message, I haven't seen the I/DEBUG messages, but I do consistently see two sets of stack traces.

Which is a bug: what seems to be happening is SIGSEGV is raised, we chain execution to Android, but Android doesn't consistently exit the process (!), so execution continues (!!), resulting in a second "unhanded exception" message from mono.

This should be fixed; we should only write the Unhandled Exception information (from mono-rt) *once*.
Comment 14 T.J. Purtell 2014-08-15 16:50:54 UTC
I think this may help https://github.com/mono/mono/pull/1206
Comment 15 T.J. Purtell 2014-11-20 15:18:57 UTC
I currently receive native crash reports on Google Play (release performed with Beta 4.20).  I think this is resolved.
Comment 16 Jonathan Pryor 2014-11-20 17:36:46 UTC
Closing as per Comment #15.

Glad it's working!
Comment 17 Rajneesh Kumar 2015-05-05 13:08:42 UTC
As per comment 15 and comment 16, this issue is resolved and working fine .

Hence I am closing this issue.

Thanks..!