Prevent Native EXC_BAD_ACCESS signal for NullRefrenceExceptions

[jamescrosswell]

Resolves #3776:

• Sentry reports handled NRE as EXC_BAD_ACCESS signal #3776

Analysis

The following all appear to impact error reporting behaviour for iOS applications:

1. The runtime (determined by whether AOT compilation is enabled or not)
2. The ObjCRuntime.MarshalManagedExceptionMode
3. Whether or not we try to suppress EXC_BAD_ACCESS errors (as in this PR)
4. Whether or not the exception is caught/ignored by managed code

MONO vs CLR Runtime

When AOT compilation is not used, .NET iOS apps use the Mono runtime. When AOT compilation is used, .NET iOS apps use the CLR runtime. Managed exceptions are marshalled differently by the two different runtimes and unwinding native exceptions is currently not supported by the CLR.

MarshalManagedExceptionMode

In earlier versions of .NET, the AppDomain.CurrentDomain.UnhandledException was not triggered correctly unless the marshalling mode for managed exceptions was set to MarshalManagedExceptionMode.UnwindNativeCode. (see xamarin/xamarin-macios#15252 and the workaround in Sentry).

This has been fixed in net9.0 on the MONO runtime.

Scenarios

I tested the various different permutations of the above, with the following results:

• EXC_BAD_ACCESS Exception scenario results

Solution

AOT / CLR

• Fix the issue of not getting NREs (unhandled exception handler not firing) in AOT Apps
  • Possibly, per Rolf's suggestion, we could intercept different events to achieve this
• Suppress EXC_BAD_ACCESS errors, to avoid duplication (this PR)

MONO

• Only use MarshalManagedExceptionMode.UnwindNativeCode when building for Mono on net8.0 and earlier #3912
  • Setting MarshalManagedExceptionMode.UnwindNative has no effect when the app is running on MONO in net9.0
  • We can't set MarshalManagedExceptionMode.UnwindNative in AOT (See Note 3)
  • Note: PR3912 may be rendered obsolete by this PR... since we no longer use AppDomain.UnhandledException
• Also suppress EXC_BAD_ACCESS errors on MONO (this PR)

Notes on EXC_BAD_ACCESS suppression

We don't know, from the stack trace, whether the EXC_BAD_ACCESS comes from native or managed code. This workaround assumes it comes from managed code and will be reported separately as a managed exception.

Prior to this PR the behaviour was the opposite. All EXC_BAD_ACCESS errors were assumed to be native exceptions and reported by the native SDK (so often users would get a EXC_BAD_ACCESS, that was a bit confusing, in addition to an NRE that makes more sense to .NET devs)

Potential alternative: add an option to let users decide whether to suppress these native errors or not.

[bruno-garcia]

This seems to only remove the events we'd like to drop. @filipnavara might have tips on how to do this better but ai think it's good enough

[bruno-garcia]

Can we have a device test that verifies this? I imagine it would only be possible if we don't actually crash the app though

[bruno-garcia]

oh we've been missing out on a category of errors?

[jamescrosswell]

Essentially, yes. Matt created this workaround to the problem (after this conversation):

sentry-dotnet/src/Sentry/Platforms/Cocoa/SentrySdk.cs

Lines 13 to 17 in c20d162

	// Workaround for https://github.com/xamarin/xamarin-macios/issues/15252
	ObjCRuntime.Runtime.MarshalManagedException += (_, args) =>
	{
	args.ExceptionMode = ObjCRuntime.MarshalManagedExceptionMode.UnwindNativeCode;
	};

However that marshalling mode isn't supported when AOT compiling iOS apps. It causes xamarin to throw an assertion error, which is unrelated to the error from the user's code.

[bruno-garcia]

It's not certain that it did crash?

[jamescrosswell]

I'm not sure about that no. We're using this event instead of AppDomain.Current.UnhandledException because Runtime.MarshalManagedException fires even in AOT compiled applications but MarshalManagedExceptionEventArgs has no equivalent of UnhandledExceptionEventArgs.IsTerminating.

I've asked the question here:

• Issues with unhandled exceptions xamarin/xamarin-macios#15252 (comment)

[bruno-garcia]

But regardless of that bool, if that fires (on your tests) the app crashes? If so, I'd indicate that's the case. But keeping it vague in here is fine, I was just wondering how this works

[jamescrosswell]

Can we have a device test that verifies this? I imagine it would only be possible if we don't actually crash the app though

Tricky... the fix is using the native.OnBeforeSend handler.

An integration test might be possible but those are quite painful to build and maintain. Ivan basically has some pwsh scripts that create new MAUI apps with csharp source code, build and run these and then watch for stuff in the logs. I think they're good for smoke testing (making sure we can build and run JIT and AOT apps that init the SDK successfully) but not a good idea to try to build more sophisticated tests that way.