Reply inline… On Dec 13, 2016, at 12:52 PM, Bernhard Urban <[email protected]> wrote: >> My recollection is that we *don’t* reliably print the managed stack trace >> during native SIGSEGV. (Am I wrong?) > > Yes. There was an issue with exceeding the altstack limit: This was > especially a problem on ARM32 because we used a pretty large struct in our > unwinding code. It’s fixed by this PR: https://github.com/mono/mono/pull/4106 > > However, this is only a workaround. Zoltan is experimenting with something > similar what we are doing for exception handling already: get out of the > signal handler via overriding the PC in the sigctx structure and then do the > heavy lifting later (that is, on a normal stack).
Good to hear. >> 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…?) > > That’s indeed correct, and setting it in the manifest for release builds > isn’t something you should do due to security reasons. Hence this PR: > https://github.com/mono/mono/pull/4131 So it sounds like all issues have been or will be addressed: * Mono will reliably dump a managed stack trace to logcat * Release apps will include `libmonosgen*.so` stack frames within the native stack trace. Thus, returning to the original question: > How about we do not even attempt to do a native stack trace in mono, but just > let debuggerd do its business? Yes? :-) - Jon _______________________________________________ Mono-devel-list mailing list [email protected] http://lists.dot.net/mailman/listinfo/mono-devel-list
