[Mono-dev] [android-devel] Runtime crashes on Android

[Jonathan Pryor]

Reply inline...

On Dec 13, 2016, at 12:26 PM, Bernhard Urban <beurba at microsoft.com> wrote:
> The audit message we see is indeed by SELinux. What happens is that we cause another SIGSEGV inside the handler. Unfortunately the kernel doesn't give us any further information. I managed to attach with lldb and the reason for the crash is that the stack pointer points into a text segment of some shared library.  WTF?

Preserving because…I just have no words. Wow.

> Let me go back one step. In general the signal chain looks like this on Android:
> 
> (1) SIGSEGV happens, the ART handler catches it and does some stuff (e.g. "is it caused by my managed code"?).
> (2) if ART doesn't know what to do, it will chain into remaining handlers. 
> (3) now it's the mono runtimes handler turn, we do our business, figure out it's a native crash, etc.
> (4) (in case we do *NOT* crash) we return to the ART handler
> (5) the ART handler now chains into the next SIGSEGV handler, which was setup by the linker of bionic.
> (6) the libc/bionic handler communicates with debuggerd which ptraces our process and delivers further information (e.g. register dump, native stack trace)
...
> Looking at this, I have this conclusion: How about we do not even attempt to do a native stack trace in mono, but just let debuggerd do its business?

What do we want? The managed callstack. Yes, a SIGSEGV happened in native code, but mono is the only one that can produce a *managed* callstack leading up to the SIGSEGV, and Android certainly isn’t going to print out the managed stack frames…

My recollection is that we *don’t* reliably print the managed stack trace during native SIGSEGV. (Am I wrong?)

So long as the managed callstack is *reliably* dumped, I don’t really care what code prints the native callstack, just that we get reliable managed and native callstacks *somewhere*, preferably in some form that will make it back to Google and developers…

However, that raises an added wrinkle: IIRC, debuggerd only attaches and dumps the stack traces for *debuggable* applications (`AndroidManifest.xml` has `//application/@android:debuggable=‘true’`). This *is not true* for Release apps, meaning we might not be able to rely on debuggerd to provide native stack traces in Release apps.

Is that a problem? (Maybe?) Are native stack dumps when Release crashes something desirable? (I’d think so…?)

 - Jon