Reply inline... On Dec 13, 2016, at 12:26 PM, Bernhard Urban <[email protected]> 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 _______________________________________________ Mono-devel-list mailing list [email protected] http://lists.dot.net/mailman/listinfo/mono-devel-list
