[Mono-dev] [android-devel] Runtime crashes on Android
jonpryor at vt.edu
Tue Dec 13 19:04:10 UTC 2016
On Dec 13, 2016, at 12:52 PM, Bernhard Urban <beurba at microsoft.com> 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?
More information about the Mono-devel-list