.Net-Android - <unknown> SIGSEGV Segfaults

[IainS1986]

We've only recently integrated Sentry into our project as a replacement for AppCenter.

We are not a MAUI project, we are just a straight .net-android and .net-ios native projects.

While testing internally, we are seeing a fair few android SIGSEGV errors coming through which show little to no real information for tracking down. I'm wondering if theres a symbolication issue we haven't got setup properly and wonder if theres some guidance on that.

The sorts of stack traces we are getting are...

OS Version: Android 14 (UKQ1.231108.001 release-keys)
Report Version: 104

Exception Type: Unknown (SIGSEGV)

Application Specific Information:
Segfault

Thread 0 Crashed:
0   libmonosgen-2.0.so              0x7d9b7e8efc        <unknown> + 539479674620
1   <unknown>                       0x7e07349ff0        <unknown>

Or

OS Version: Android 14 (AP2A.240605.024)
Report Version: 104

Exception Type: Unknown (SIGSEGV)

Application Specific Information:
Segfault

Thread 0 Crashed:
0   split_config.arm64_v8a.apk      0x77ad1a0efc        <unknown> + 514005274364
1   <unknown>                       0x1                 <unknown>

With the image viewer showing missing images...

The breadcrumbs show some in similar 'places' but theres also a bit of a random array of times the crashes appeared to occur.

There also seem to be more happening than people are really reporting too me.

Is there anyway to get more information for these stack traces?
We upload the mappings.txt file for proguard, but we don't upload symbolication symbols. Where would they 'be' once built and how do we upload them?

We do all our uploading via DevOps and the API - so I'm assuming we would upload something like so,
'sentry-cli debug-files upload -o $(sentry.org.slug) -p $(sentry.project.android) $(Pipeline.Workspace)/$(artifact.name)/somesymbolfile'

But I'm not 100% on what symbol files there are than can be uploaded.

[IainS1986]

So brief googling i've seen some talks about the Concurrent GC being an issue in .net-android
dotnet/maui#21479 and
dotnet/runtime#105389

So I'm assuming theres no actual extra information that Sentry could have given for these anyway as I think its a GC issue.

But.

I just want to clarify if there is anything other than the mappings.txt that can be uploaded to aid with any desymbolication of errors?

[jamescrosswell]

Hi @IainS1986 ,

Thanks for reaching out. I think what you're seeing is a Sentry problem (nothing to do with concurrent GC). We've had a couple of different related reports and the discussions ramble a bit, so I've created a summary issue here:

• Managed NullReferenceException causes SIGSEGV errors on iOS and Android  #3902

In the short term then, we need to disable the Native Crash reporting capability that we're wrapping from the .NET SDK... this way you'll only receive managed exceptions (not native ones).

Eventually, we need to work out how to make the two play more nicely together so that you can get native crash reports as well, but only when these relate to exceptions that aren't already handled in managed code.

Apologies for the inconvenience - this is a bit of a tricky issue to diagnose and fix, as it spans quite a few different platforms and technologies.

[IainS1986]

Cheers, good to know!

I assume there's nothing currently that can be configured to ignore the ndk - it's a future update?

[jamescrosswell]

Cheers, good to know!

I assume there's nothing currently that can be configured to ignore the ndk - it's a future update?

Yeah, on Android it's actually used by the Java SDK (which the .NET SDK uses). So making that fix involves coordinating and testing changes across a couple of different repositories, which is what makes it tricky.

I can possibly use the BeforeSend hook to ignore all/any SIGSEGV reports from the Native SDK as a short term workaround. I'll experiment with that a little later today.

[jamescrosswell]

So @IainS1986, I had a further look into this and actually there is already an option that you can use to disable the Native SDK when initialising the .NET SDK on Android:

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

The default value for EnableNdk is true, but I think we'll make a new release of the .NET SDK changing that default value until we can work through the issues in #3902 .

Making this change avoids SIGSEGV errors that get thrown erroneously when a managed NullReferenceException is thrown.

It would be interesting to know whether it resolves the issues you're seeing.

[IainS1986]

@jamescrosswell so its very early days as I only did a build on Friday with that EnableNdk change.

So far I had 2 people in our team/company who had fairly reliably recreated the issue - and since using the new build they are reporting that it seems 'fine' now and I've not seen any errors on Sentry.

They were actually getting crashes so it wans't just a silent exception through to Sentry. However I also included a couple other fixes in the build so I'm not 100% on which fixed the issue, or if it was even a combination of many,

• AndroidEnableSGenConcurrent was set to false
• EnableNdk was set to false
• Sentry was updated from 5.0.0 -> 5.0.1

I'll monitor for the rest of the week and see if any more appear, 🤞 its maybe sorted.