Managed NullReferenceException causes EXC_BAD_ACCESS and SIGSEGV errors on iOS and Android

[jamescrosswell]

Problem

When the Sentry Native SDK is used in apps that are AOT compiled (for example when publishing Android or iOS apps in release mode), SIGSEGV reports are captured by the NDK for managed NullReferenceException exceptions, even when the managed code in question catches and handles such exceptions.

Steps to reproduce

• Create a MAUI app
• Add a button with some code that will generate a NullReferenceException in the event handler... e.g.:

          string s = null;
        _logger.LogInformation("The length of the string is {StringLength}", s!.Length);
  

• Run the application in Release mode on a Simulator

Expected Result

A managed NullReferenceException should be captured by the .NET SDK

Actual Result

In addition to a NullReferenceException being captured by the .NET SDK, SIGSEGV signal error is captured by the NDK (on Android) or the CocoaSDK (on iOS).

Analysis

Full analysis from @supervacuus here:

• SIGSEGV reported by Sentry when a NullReferenceException is thrown in Release mode dotnet/android#9055 (comment)

On the basis of the analysis above, we attempted to invert the order in which the Native and Managed signal handlers get run in this PR:

• https://github.com/getsentry/sentry-dotnet/pull/3694/files#diff-382226eacb7ee000748a4a5ea92c800b032a7225426a84d1e945e5aff7f20011

However this led to users' applications crashing (rather than just reporting erroneous SIGSEGV errors). So this change was reverted in:

• Revert signal handler chaining order (PR #3694) #3871

Gist

📄 NullReference SIGSEGV Exception.pdf

Current State

We don't have the required resources available on the Native team to solve this end-to-end at the moment, so coming back to #3861 (comment), we need to recommend deactivating the native crash reporters on Android and iOS for MAUI for the time being to mitigate the issue of duplicate reports.

However we're in the process of getting more resources on the downstream team(s) which means we'll hopefully be able to tackle the root cause some time in the next few months.

Originally posted by @kahest in #3861

Workaround (short term)

In the short term, we will try to disable Native Crash reporting of SIGSEGV exceptions.

• Disable the NDK when initialising the Sentry SDK for Java on Android from the .NET SDK
• Prevent Native EXC_BAD_ACCESS signal for NullRefrenceExceptions #3909

Solution (long term)

Eventually, we need to work out how to make the dotnet and native SDKs play nicely together, so that native exceptions are captured, but only when they have not already been translated to and captured as managed exceptions.

Related issues

Android

• SIGSEGV when a NullReferenceException is thrown in Release mode #3861
• C# Maui.Android Release Mode SIGSEGV #3837
• .Net-Android - <unknown> SIGSEGV Segfaults #3898

iOS

• Sentry reports handled NRE as EXC_BAD_ACCESS signal #3776

[jamescrosswell]

Everything we can do on this issue has now be done.

I've created #3954 to investigate a long term solution.