This is a spin-off bug from bug #4120.
Currently for SIGSEGVs, Mono will:
1) Handle the SIGSEGV
2) Check if it's in managed code (if it is, throw a NullReferenceException. That's not what this bug is about).
3) If in native code, print diagnostics to stderr/logs.
4) Raise SIGABRT.
The problem here is 4), when raising SIGABRT the register/thread/process state from the SIGSEGV is lost, and it may contain information crucial to diagnose a crash (see bug #4120, comments 22/24 for examples).
1) Add support to enable crash chaining . This must be opt-in, because currently crash reporters depend on us raising SIGABRT for SIGSEGVs we recognize as NullReferenceExceptions .
a) Using an argument to mtouch: --enable-crash-chaining. Pro: easy to implement. Con: hard to set from third-party libraries (which is usually how crash reporters are consumed by customers).
b) Using an assembly-level attribute. [assembly: CrashChaining (true)]. Con: harder to implement (but not very hard I think). Pro: can easily be configured from third-party libraries.
2) Add support for providing a native method that initializes crash reporters (so that the signal handlers for the crash reporter is installed before Mono's).
a) Using an argument to mtouch. --crash-reporter-initialization-function:<function name>
b) Using an assembly-level attribute.
Same cons/pros as for 1).
3) Add support for 1) and 2) to Xamarin.Insights.
2) Is already implemented: https://github.com/mono/mono/commit/aaaead4. This will be in C9.
There's also another option for 1):
c) Automatically detect apps that call https://github.com/mono/mono/commit/aaaead4, and then enable crash chaining.