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

[Jonathan Pryor]

Reply inline…

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?

Yes? :-)

 - Jon