SIGSEGV reported by Sentry when a NullReferenceException is thrown in Release mode

[tranb3r]

Android framework version

net8.0-android

Affected platform version

VS 2022 17.10.0

Description

I'm getting SIGSEGV reports from Sentry when running my Maui app on Android.
I've norrowed it down to a NullReferenceException happening in Release mode.
However, I don't understand why I get both a NullReferenceException and a SIGSEGV, since I'm using only managed code.
Even when I catch the NullReferenceException, the SIGSEGV still occurs, without the app actually crashing.
Also, I haven't seen anything weird in the log. How is Sentry catching this SIGSEGV? I'm lost here...
Could you please take a look at my repro? https://github.com/tranb3r/Issues/tree/main/MauiAppSegfault

Steps to Reproduce

1. Open repro app in Visual Studio and set your Dsn for Sentry before running the app.
2. Run the app in Release mode on Android.
3. Tap on Run button. A NullReferenceException happens but it's catched silently.
4. Close the app, launch it again. An error report with SIGSEGV is sent to Sentry immediately.

Did you find any workaround?

No workaround.

Relevant log output

No response

[grendello]

@tranb3r considering I have no idea what Sentry is and how to use it, I will need more info from you :)

Can you add to this issue logcat output with the segfault, as well as the managed exception strack trace?

The fact that you don't use native code directly doesn't mean it isn't involved, in fact, it's always involved in one manner or another.

If you're able to reproduce this issue locally, please capture logcat output using the following commands:

> adb shell setprop debug.mono.log default,assembly,mono_log_level=debug,mono_log_mask=all
> adb logcat -G 64M
> adb logcat -c
rem Start and crash the app here, wait 2-3 seconds and then:
> adb logcat -d > logcat.txt

[tranb3r]

considering I have no idea what Sentry is and how to use it, I will need more info from you :)

@grendello
Sentry is cloud-based error tracking for applications.
If you want to reproduce this issue on your machine, you can create a free account in 2 minutes, and then simply copy your account id (it's called DSN) into MauiProgram.cs.

Can you add to this issue logcat output with the segfault, as well as the managed exception strack trace?

The manage exception is catched. I've added an INFO log so you can see it in the logcat.

06-27 14:20:50.722 11869 11869 I MauiAppSegFault: System.NullReferenceException: Object reference not set to an instance of an object
06-27 14:20:50.722 11869 11869 I MauiAppSegFault:    at MauiAppSegfault.MainPage.Button_OnClicked(Object sender, EventArgs e)

The application is not crashing, and I haven't seen a trace for the Segfault.
But Sentry is capturing it, so it must be somewhere.

So here are two logcats:

• first is a repro WITH sentry : run app, click on Run button, exception is catched, close app, run it again, Segfault is sent to Sentry.
  logcat_with_sentry.txt
• second is a repro WITHOUT sentry : run app, click on Run button, exception is catched, close app, run it again.
  logcat_without_sentry.txt

[grendello]

@tranb3r thanks, I'd still like to see the error your instance of Sentry records, the one with SIGSEGV. It would be helpful if you pasted it (and whatever context surrounds it) here.

[tranb3r]

[tranb3r]

@grendello
I've posted screenshots of everything I can see in Sentry.

[grendello]

@tranb3r thanks! They clearly have the whole stack trace somewhere, since without it they wouldn't show the registers nor the frame where it happens. Alas, their UI made the trace useless - could you try digging in the UI to find the raw data they parse?

[tranb3r]

I really think that's everything I can get from the UI.

Adding @jamescrosswell , hope you don't mind.
James, maybe you can provide more context?

[grendello]

It's too bad the raw data is missing. With these crashes the context is everything - not just the header, but most importantly the frames themselves. With some kinds of signals (e.g. SIGABRT) lines preceding the native trace are often crucial. Contents of registers, as shown in the screenshot, is mostly of secondary interest - they don't give us any information about the location of the crash (except of, in this case, the RPI register which points to code position at the crash) with regards to source code. Even if the trace doesn't contain file:line information, it contains addresses relative to the loaded shared libraries/executables and we can post-mortem translate them to code location (not always, but in most cases). The information contained in the UI above is, alas, not helpful.

[tranb3r]

Here is the data that is saved by Sentry when the error occurs. It contains a bit more than what is visible in the UI. Maybe you can take a look?
68e4d535-186b-42dc-56f2-c213526eed94.envelope.json