C# Maui.Android Release Mode SIGSEGV

[gwise-vision]

Environment

SaaS (https://sentry.io/)

Steps to Reproduce

When deploying in release mode in C# Maui.Android, Sentry crashes every time. The Android app does not crash, but only the Sentry log is as follows:

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[getsantry]

Routing to @getsentry/product-owners-issues for triage ⏲️

[mrduncan]

@ReneGreen27 am I misunderstanding, this seems like an SDK issue?

[jamescrosswell]

Possibly related to:

• Either fix: Android - make sure logcat.log is attached to unhandled event (SIGSEGV Segfault) #3694
• Or NETWORK_CAPABILITIES_CHANGED and BATTERY_CHANGED events on Android (with Maui) causing SIGSEGV Segfault #3828

We have a fix for the first in the pipeline. The second one I haven't had a chance to look at yet.

[jamescrosswell]

@gwise-vision we just released version 5.0.0 of the SDK, which includes the fix from #3694. Are you able to update to version 5 to see if that fix is related to the issue you're experiencing?

The other thing to check would be that you're not enabling AOT compilation as this isn't yet supported on Android.

[jamescrosswell]

@gwise-vision just following up on this. It looks like this is due to the way the Native SDK for Sentry interacts with the .NET SDK for Sentry. As a workaround, for the time, you can disable the Native SDK when initialising Sentry on Android:

#if ANDROID
             options.Native.EnableNdk = false;
#endif

The default value for EnableNdk is true. We'll make a new release to change that default value until we can properly work through the issues with the Native SDK. See #3902 for further information.

[gwise-vision]

@gwise-vision just following up on this. It looks like this is due to the way the Native SDK for Sentry interacts with the .NET SDK for Sentry. As a workaround, for the time, you can disable the Native SDK when initialising Sentry on Android:

#if ANDROID
options.Native.EnableNdk = false;
#endif
The default value for EnableNdk is true. We'll make a new release to change that default value until we can properly work through the issues with the Native SDK. See #3902 for further information.

OK~

[gwise-vision]

#if ANDROID
options.Native.EnableNdk = false;
#endif
This is not resolved in sentry.maui 5.0.1 either.
Shouldn't AOT be applied when deploying on Android?

[gwise-vision]

When will this bug be fixed?
options.Native.EnableNdk = false; It still happens.
(Sentry.Maui 5.0.1)
This bug is limiting free Sentry usage.

[jamescrosswell]

@gwise-vision this issue is at the top of the backlog. I've been busy digging into a similar problem on iOS over the last couple of weeks (so haven't been able to look into this one on Android yet).

It's very odd that you see a SIGSEGV after disabling the NDK. Can you check (on the bug report that you see in Sentry) which SDK reported the bug? If you scroll down underneath the list of Assemblies there should be an SDK section with the name and version of the SDK. It would be strange to see a SIGSEGV reported by the .NET SDK as the runtime should ordinarily capture these and translate them into managed exceptions.

[gwise-vision]

@gwise-vision this issue is at the top of the backlog. I've been busy digging into a similar problem on iOS over the last couple of weeks (so haven't been able to look into this one on Android yet).

It's very odd that you see a SIGSEGV after disabling the NDK. Can you check (on the bug report that you see in Sentry) which SDK reported the bug? If you scroll down underneath the list of Assemblies there should be an SDK section with the name and version of the SDK. It would be strange to see a SIGSEGV reported by the .NET SDK as the runtime should ordinarily capture these and translate them into managed exceptions.

Event Log
https://us.sentry.io/api/0/projects/gwise/maui-expirydate/events/0832b880c2e44779626b6f86e430902f/json/

"environment": "production",
"exception": {
"values": [
{
"type": "SIGSEGV",
"value": "Segfault",
"stacktrace": {
"frames": [
{
"package": "/data/app/~~a04JfcWuMoNojiXYoPPySQ==/com.gwise.expirydate-BMjCi7mM2qrqv57sCMwhAA==/split_config.arm64_v8a.apk",
"in_app": false,
"data": {
"orig_in_app": -1,
"symbolicator_status": "missing"
},
"image_addr": "0x7682c44000",
"instruction_addr": "0x7682c65ea8"
}
],
"registers": {
"fp": "0x7fc79f2410",
"lr": "0x60",
"pc": "0x7682c65ea8",
"sp": "0x7fc79f2410",
"x0": "0x0",
"x1": "0x0",
"x10": "0x1",
"x11": "0x1",
"x12": "0x0",
"x13": "0x0",
"x14": "0xb4000076c8e35bf8",
"x15": "0xb4000075cd3bd868",
"x16": "0x7682cb0de0",
"x17": "0x0",
"x18": "0x77cebc6000",
"x19": "0xb4000077cdc35400",
"x2": "0x75f818e790",
"x20": "0x0",
"x21": "0x0",
"x22": "0x75f818bc20",
"x23": "0x75f818be60",
"x24": "0x7",
"x25": "0x7640159060",
"x26": "0x18200001",
"x27": "0x0",
"x28": "0x7fc79f26d4",
"x3": "0x0",
"x4": "0xb4000075cd507cb0",
"x5": "0xb4000075f1bdc940",
"x6": "0xb4000075cb40e080",
"x7": "0xb4000075cb40e080",
"x8": "0x77ce4e81c0",
"x9": "0x0"
},
"instruction_addr_adjustment": "none"
},
"raw_stacktrace": {
"frames": [
{
"package": "/data/app/~~a04JfcWuMoNojiXYoPPySQ==/com.gwise.expirydate-BMjCi7mM2qrqv57sCMwhAA==/split_config.arm64_v8a.apk",
"in_app": false,
"data": {
"orig_in_app": -1
},
"image_addr": "0x7682c44000",
"instruction_addr": "0x7682c65ea8"
}
],
"registers": {
"fp": "0x7fc79f2410",
"lr": "0x60",
"pc": "0x7682c65ea8",
"sp": "0x7fc79f2410",
"x0": "0x0",
"x1": "0x0",
"x10": "0x1",
"x11": "0x1",
"x12": "0x0",
"x13": "0x0",
"x14": "0xb4000076c8e35bf8",
"x15": "0xb4000075cd3bd868",
"x16": "0x7682cb0de0",
"x17": "0x0",
"x18": "0x77cebc6000",
"x19": "0xb4000077cdc35400",
"x2": "0x75f818e790",
"x20": "0x0",
"x21": "0x0",
"x22": "0x75f818bc20",
"x23": "0x75f818be60",
"x24": "0x7",
"x25": "0x7640159060",
"x26": "0x18200001",
"x27": "0x0",
"x28": "0x7fc79f26d4",
"x3": "0x0",
"x4": "0xb4000075cd507cb0",
"x5": "0xb4000075f1bdc940",
"x6": "0xb4000075cb40e080",
"x7": "0xb4000075cb40e080",
"x8": "0x77ce4e81c0",
"x9": "0x0"
}
},
"mechanism": {
"type": "signalhandler",
"synthetic": true,
"handled": false,
"meta": {
"signal": {
"number": 11,
"name": "SIGSEGV"
}
}
}
}
]
},
"fingerprint": [
"{{ default }}"
],
"grouping_config": {
"enhancements": "KLUv_SAYwQAAkwKRs25ld3N0eWxlOjIwMjMtMDEtMTGQ",
"id": "newstyle:2023-01-11"
},
"hashes": [
"6dec3eff895251a583a6983d621296b4"
],
"ingest_path": [
{
"version": "25.1.0",
"public_key": "XE7QiyuNlja9PZ7I9qJlwQotzecWrUIN91BAO7Q5R38"
}
],
"key_id": "4008645",
"level": "fatal",
"logger": "",
"metadata": {
"in_app_frame_mix": "system-only",
"value": "Segfault"
},
"nodestore_insert": 1738537475.51658,
"received": 1738537473.71517,
"sdk": {
"name": "sentry.native.android.dotnet",
"version": "0.7.16",
"integrations": [
"inproc"
],
"packages": [
{
"name": "github:getsentry/sentry-native",
"version": "0.7.16"
}
]
},
"timestamp": 1738536745.078,
"title": "\u003Cunknown\u003E",
"type": "error",
"user": {
"id": "aa7cc6ce-cff7-4d8d-b6d3-f6c34624f62b",
"ip_address": "211.235.64.213",
"sentry_user": "id:aa7cc6ce-cff7-4d8d-b6d3-f6c34624f62b",
"geo": {
"country_code": "KR",
"city": "Buk-gu",
"subdivision": "Daegu",
"region": "South Korea"
}
},
"version": "7",
"location": null
}

[jamescrosswell]

Thanks @gwise-vision - that's definitely coming from the Native SDK:

"name": "sentry.native.android.dotnet",
"version": "0.7.16"

We set the name here to distinguish these reports from crashes that are reported by the Native SDK that aren't from Android apps built with .NET:

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

Line 141 in 3f63cb6

o.NativeSdkName = "sentry.native.android.dotnet";

But that version number definitely corresponds to the NDK.

About the only thing I can think that might have happened is that a crash report might have been created before you disabled the NDK and cached on the file system (this happens when an error crashes the application - the idea is that it will be sent on startup next time you run the application)... and then when you ran the app again with the NDK disabled, that old crash report might have been sent.

In any event, I'll look into an alternative workaround to this as we'd rather not disable the NDK entirely... it's really good to have it there catching native crashes, more generally. We just don't want it capturing signal errors for exceptions that have already been wrapped and reported as managed exceptions by the .NET SDK. We just made a similar fix for EXC_BAD_ACCESS mach exceptions on iOS by using the BeforeSend hook in the Native SDK so I'll see if we can do something similar on Android... it's more complex on Android since there's another level of indirection (.NET -> Java -> Native), but we'll see.

[jamescrosswell]

@gwise-vision I just started looking into this issue today and I can't reproduce it. I tweaked the Sentry.Samples.Maui project so that the managed crashes are caused by NREs... e.g.:

    private void OnCapturedExceptionClicked(object sender, EventArgs e)
    {
        try
        {
            string s = null;
            _logger.LogInformation("The length of the string is {StringLength}", s!.Length);
        }
        catch (Exception ex)
        {
            SentrySdk.CaptureException(ex);
        }
    }

Then I'm running this in release mode on a simulator:

dotnet build ./samples/Sentry.Samples.Maui/Sentry.Samples.Maui.csproj /p:_IsPublishing=true -t:Run -c Release -f net9.0-android35.0

But I'm getting plain old managed NullReferenceExceptions being captured and reported to Sentry (no SIGSEGV).

I'm wondering if this is something to do with your solution/project configuration. Are you able to share that with me so that I can try to reproduce this?

Shouldn't AOT be applied when deploying on Android?

See this comment.

There's an open issue looking into AOT compilation on Android:

• See if we can use $(AndroidAotMode)=full MONO_AOT_MODE_FULL dotnet/android#9469

[gwise-vision]

C# maui.android release settings options.
This error does not occur on iOS.

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
  <AndroidStoreUncompressedFileExtensions>.mp3;.otf;.ttf;.png</AndroidStoreUncompressedFileExtensions>
	<EnableLLVM>False</EnableLLVM>
	<AndroidEnableProfiledAot>True</AndroidEnableProfiledAot>
	<RunAOTCompilation>True</RunAOTCompilation>
	<PublishTrimmed>True</PublishTrimmed>
	<AndroidEnableSGenConcurrent>True</AndroidEnableSGenConcurrent>
	<AndroidPackageFormat>aab</AndroidPackageFormat>
	<AndroidUseAapt2>True</AndroidUseAapt2>
	<AndroidCreatePackagePerAbi>False</AndroidCreatePackagePerAbi>
	<RuntimeIdentifiers>android-arm;android-arm64</RuntimeIdentifiers>
</PropertyGroup>

[jamescrosswell]

Thanks @gwise-vision - it's possibly related to the concurrent garbage collection (seems to be an issue with MAUI itself, rather than Sentry):

• .Net-Android - <unknown> SIGSEGV Segfaults #3898 (comment)

However, you might also get this if you're using version 5.0.0 of the Sentry SDK. This was the main reason for the 5.0.1 point release. As of today though, you're probably best upgrading to 5.1.0. Are you currently using version 5.0.0 by any chance?

[gwise-vision]

Thanks @gwise-vision - it's possibly related to the concurrent garbage collection (seems to be an issue with MAUI itself, rather than Sentry):

• .Net-Android - SIGSEGV Segfaults #3898 (comment)

However, you might also get this if you're using version 5.0.0 of the Sentry SDK. This was the main reason for the 5.0.1 point release. As of today though, you're probably best upgrading to 5.1.0. Are you currently using version 5.0.0 by any chance?

Current Version : Sentry.Maui --version 5.0.1

[jamescrosswell]

OK, I'm finally seeing SIGSEGV exceptions. The secret was:

• Don't run the app from JetBrains rider (run it from the simulator directly)
• Throw an exception that crashes the app (not one that is caught by a try..catch block).

I should be able to suppress these now:

• Suppress Native SIGSEGV signal errors on Android #3903