MAUI + .Net for Android/iOS - Crashes Duplicated

[justinwojo]

Package

Sentry

.NET Flavor

.NET

.NET Version

9.0.203

OS

Other

OS Version

No response

Development Environment

Rider 2024 (MacOS)

SDK Version

5.4.0

Self-Hosted Sentry Version

No response

Workload Versions

android 35.0.61/9.0.100 SDK 9.0.200
ios 18.4.9288/9.0.100 SDK 9.0.200
maui 9.0.14/9.0.100 SDK 9.0.200
maui-android 9.0.14/9.0.100 SDK 9.0.200
maui-ios 9.0.14/9.0.100 SDK 9.0.200

UseSentry or SentrySdk.Init call

`

SentrySdk.Init(options =>
    {
        options.Dsn = "removed";
        options.SampleRate = 1.0F;
        options.TracesSampleRate = 1.0;
        options.ProfilesSampleRate = 1.0;

        options.Native.EnableAppHangTracking = true;
        options.Native.EnableTracing = true;

        options.Environment = AppConfig.Environment;

        options.CacheDirectoryPath = Path.GetTempPath();
    });

`

Steps to Reproduce

Have a crash in a MAUI, .Net for iOS, or .Net for Android app caused by a .Net unhandled exception. You'll see the crash listed as 2 separate unhandled exceptions in the issue screen when filtering by unhandled true.

When using the Dashboard widget for crash counts, you'll see this crash listed as 2 crashes and 2 users, instead of just 1. We have both MAUI and .Net for Android/iOS apps that all exhibit the same behavior, and at larger scale than this example.

Given the example above affecting 2 users, 3 total crashes, the dashboard shows this as 4 affected users, 6 crashes, and a much higher percentage of sessions/users with crashes than what is true.

Expected Result

The .Net unhandled exception and the native crash should not be counted as 2 different crashes in Sentry, especially when wanting to use the Dashboard widgets to properly determine crash counts and rates.

Also, since there's no way to change the releases crash rate widget by only fatal level, we cannot find a way to display a widget showing percentage of sessions that crashed with fatal unhandled errors, since sessions cannot be used as a metric within the error widget in a formula. So, we're unable to actually properly reflect the true percentage of users with crashes in the dashboard without manually calculating it.

Actual Result

Listed in Steps to Reproduce. Every crash regardless of iOS or Android results in 2 different issue reports, and 2 crashes added to the total crash count instead of just 1.

[bruno-garcia]

We need a clear way to know if .NET is getting a native signal and making a C# exception out of that.
My understanding is that some things simply can't be done in signal handlers. It might just deadlock or crash.

The goal of having proper native crash reporting in Sentry is to capture bugs that would otherwise go unnoticed since these are not managed crashes.
But it's not clear to me what exactly .NET (Mono? Is it the same on CoreCLR Native AOT?) does in signal handlers wrt translating native crashes to C# exception.

From my tests a whole ago, if I spawned a Java thread and throw an exception there, .NET didn't capture that:

sentry-dotnet/lib/sentry-android-supplemental/Buggy.java

Line 13 in bb765ee

throw new RuntimeException(msg);

Similarly if I P/Invoked into a native function and segfaulted, .NET wouldn't capture that either:

sentry-dotnet/lib/sentrysupplemental/sentrysupplemental.c

Lines 4 to 5 in bb765ee

	char *ptr = 0;
	*ptr += 1;

Is that not the case anymore? What does .NET manage to bring back into managed-land and what does it not?
With that information we'll be able to adjust this SDK to make sure we're not double reporting events.

[jamescrosswell]

btw @justinwojo if you really really want to, you can suppress the SIGABRT errors. See:

• Add option to enable/disable EXC_BAD_ACCESS suppression #3998

Use with caution, however... as it's entirely possible this suppresses signal errors that are not marshalled and also raised as managed exceptions (in which case your app will crash and you won't know about it).

[justinwojo]

btw @justinwojo if you really really want to, you can suppress the SIGABRT errors. See:

• Add option to enable/disable EXC_BAD_ACCESS suppression #3998

Use with caution, however... as it's entirely possible this suppresses signal errors that are not marshalled and also raised as managed exceptions (in which case your app will crash and you won't know about it).

Ahhh thanks for that link. I didn't realize there were similar reports and workarounds from before, I missed them when I was searching for similar issue reports.

We'll experiment with these flags and the callbacks to see if they will work for us, or we'll just wait to see if there's a better longterm solution on #3954