SIGSEGV when a NullReferenceException is thrown in Release mode #3861

tranb3r · 2024-12-20T09:16:20Z

Package

Sentry.Maui

.NET Flavor

.NET

.NET Version

9.0.0

OS

Android

SDK Version

35

Self-Hosted Sentry Version

No response

Steps to Reproduce

Repro app : https://github.com/tranb3r/Issues/tree/main/MauiAppSegfault

Open repro app in Visual Studio and set your Dsn for Sentry before running the app. Check Sentry.Maui version in csproj.
Run the app in Release mode on Android.
Tap on Run button. A NullReferenceException happens.
With Sentry.Maui 4.x, the exception is catched silently. Close the app, launch it again. An error report with SIGSEGV is sent to Sentry immediately.
With Sentry.Maui 5.0.0, even if the exception is catched, the app crashes. Launch the app again. An error report with SIGSEGV is sent to Sentry.

Expected Result

No crash. No SIGSEGV report by Sentry.

Actual Result

With 4.x : no crash but SIGSEGV report by Sentry.
With 5.0 : app crashes and SIGSEGV report is sent by Sentry.
Without Sentry.Maui : no crash (exception is catched).

Related issues/PRs

dotnet/android#9055
#3461
#3694

bruno-garcia · 2024-12-23T16:10:12Z

Thank you so much for the repro, steps and the ticket.
For now hope you can stick to the latest 4.x release. We'll dig into this asap.

phunkeler · 2024-12-31T21:30:31Z

I don't have much to add here other than a few investigative notes/artifacts:

logcat

--------- beginning of main
12-31 16:01:05.072 20128 20128 D Mono    : AOT: FOUND method Android.Runtime.JNINativeWrapper:Wrap_JniMarshal_PPL_Z (_JniMarshal_PPL_Z,intptr,intptr,intptr) [0x70ca9be9ac00 - 0x70ca9be9ad38 0x70ca9beca41a]
12-31 16:01:05.072 20128 20128 D Mono    : AOT: NOT FOUND: Android.App.Activity:n_DispatchTouchEvent_Landroid_view_MotionEvent_ (intptr,intptr,intptr).
12-31 16:01:05.073 20128 20128 D monodroid-assembly: typemap: java type 'android/view/MotionEvent' corresponds to managed token id 33554937 (0x20001f9)
12-31 16:01:05.074 20128 20128 D monodroid-assembly: typemap: MVID [01128D64-8BBC-4364-AB86-D1D7C3E658F9] maps to assembly Mono.Android, looking for token 33554937 (0x20001f9), table index 505
12-31 16:01:05.074 20128 20128 D monodroid-assembly: typemap: type with token 33554937 (0x20001f9) in module {01128D64-8BBC-4364-AB86-D1D7C3E658F9} (Mono.Android) corresponds to Java type 'android/view/MotionEvent'
12-31 16:01:05.074 20128 20128 D Mono    : AOT: NOT FOUND: Android.Views.MotionEvent:.ctor (intptr,Android.Runtime.JniHandleOwnership).
12-31 16:01:05.075 20128 20128 D Mono    : Running class .cctor for Android.Views.MotionEvent from 'Mono.Android'
12-31 16:01:05.075 20128 20128 D Mono    : AOT: NOT FOUND: Android.Views.MotionEvent:.cctor ().
12-31 16:01:05.076 20128 20128 D Mono    : AOT: NOT FOUND: Android.Views.InputEvent:.ctor (intptr,Android.Runtime.JniHandleOwnership).
12-31 16:01:05.077 20128 20128 D Mono    : Running class .cctor for Android.Views.InputEvent from 'Mono.Android'
12-31 16:01:05.077 20128 20128 D Mono    : AOT: NOT FOUND: Android.Views.InputEvent:.cctor ().
12-31 16:01:05.078 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.MauiAppCompatActivity:DispatchTouchEvent (Android.Views.MotionEvent).
12-31 16:01:05.078 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.MauiAppCompatActivity:DispatchTouchEvent (Android.Views.MotionEvent).
12-31 16:01:05.079 20128 20128 D Mono    : AOT: NOT FOUND: Android.App.Activity:DispatchTouchEvent (Android.Views.MotionEvent).
12-31 16:01:05.081 20128 20128 D Mono    : AOT: NOT FOUND: Android.Runtime.JNINativeWrapper:Wrap_JniMarshal_PPLL_Z (_JniMarshal_PPLL_Z,intptr,intptr,intptr,intptr).
12-31 16:01:05.083 20128 20128 D Mono    : AOT: NOT FOUND: Android.Views.View/IOnTouchListenerInvoker:n_OnTouch_Landroid_view_View_Landroid_view_MotionEvent_ (intptr,intptr,intptr,intptr).
12-31 16:01:05.084 20128 20128 D Mono    : AOT: NOT FOUND: Android.Views.View/IOnTouchListenerImplementor:OnTouch (Android.Views.View,Android.Views.MotionEvent).
12-31 16:01:05.084 20128 20128 D Mono    : AOT: NOT FOUND: Android.Views.View/TouchEventArgs:.ctor (bool,Android.Views.MotionEvent).
12-31 16:01:05.085 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.WindowOverlay:TouchLayerTouch (object,Android.Views.View/TouchEventArgs).
12-31 16:01:05.086 20128 20128 D Mono    : AOT: NOT FOUND: Android.Views.MotionEvent:get_Action ().
12-31 16:01:05.087 20128 20128 D Mono    : AOT: NOT FOUND: Android.Views.MotionEvent:get_RawX ().
12-31 16:01:05.088 20128 20128 D Mono    : AOT: FOUND method Java.Interop.JniPeerMembers/JniInstanceMethods:InvokeAbstractSingleMethod (string,Java.Interop.IJavaPeerable,Java.Interop.JniArgumentValue*) [0x70cb2ec5d030 - 0x70cb2ec5d16f 0x70cb2ec67c9c]
12-31 16:01:05.088 20128 20128 D Mono    : AOT: FOUND method Java.Interop.JniPeerMembers/JniInstanceMethods:TryInvokeSingleStaticRedirect (Java.Interop.JniMethodInfo,Java.Interop.IJavaPeerable,Java.Interop.JniArgumentValue*,single&) [0x70cb2ec5ce70 - 0x70cb2ec5d029 0x70cb2ec67c98]
12-31 16:01:05.088 20128 20128 D Mono    : AOT: FOUND method Java.Interop.JniEnvironment/InstanceMethods:CallFloatMethod (Java.Interop.JniObjectReference,Java.Interop.JniMethodInfo,Java.Interop.JniArgumentValue*) [0x70cb2ec4f0d0 - 0x70cb2ec4f31e 0x70cb2ec67808]
12-31 16:01:05.088 20128 20128 D Mono    : AOT: FOUND method (wrapper managed-to-native) <Module>:wrapper_native_indirect_single_intptr_intptr_intptr_intptr (intptr&,intptr,intptr,intptr,intptr) [0x70cb2ec62be0 - 0x70cb2ec62d08 0x70cb2ec67e72]
12-31 16:01:05.088 20128 20128 D Mono    : AOT: NOT FOUND: Android.Views.MotionEvent:get_RawY ().
12-31 16:01:05.089 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.WindowOverlay:OnTappedInternal (Microsoft.Maui.Graphics.Point).
12-31 16:01:05.090 20128 20128 D Mono    : Running class .cctor for System.Collections.Generic.List`1<Microsoft.Maui.IWindowOverlayElement> from 'System.Private.CoreLib'
12-31 16:01:05.090 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.WindowOverlayTappedEventArgs:.ctor (Microsoft.Maui.Graphics.Point,System.Collections.Generic.IList`1<Microsoft.Maui.IVisualTreeElement>,System.Collections.Generic.IList`1<Microsoft.Maui.IWindowOverlayElement>).
12-31 16:01:05.091 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.VisualDiagnosticsOverlay:VisualDiagnosticsOverlayOnTapped (object,Microsoft.Maui.WindowOverlayTappedEventArgs).
12-31 16:01:05.092 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Handlers.ButtonHandler/ButtonTouchListener:OnTouch (Android.Views.View,Android.Views.MotionEvent).
12-31 16:01:05.092 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Handlers.ButtonHandler:OnTouch (Microsoft.Maui.IButton,Android.Views.View,Android.Views.MotionEvent).
12-31 16:01:05.093 20128 20128 D Mono    : AOT: NOT FOUND: Android.Views.MotionEvent:get_ActionMasked ().
12-31 16:01:05.093 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:Microsoft.Maui.IButton.Pressed ().
12-31 16:01:05.093 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:Microsoft.Maui.IButton.Pressed ().
12-31 16:01:05.094 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:SendPressed ().
12-31 16:01:05.095 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.ButtonElement:ElementPressed (Microsoft.Maui.Controls.VisualElement,Microsoft.Maui.Controls.Internals.IButtonElement).
12-31 16:01:05.095 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:Microsoft.Maui.Controls.Internals.IButtonElement.SetIsPressed (bool).
12-31 16:01:05.095 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:Microsoft.Maui.Controls.Internals.IButtonElement.SetIsPressed (bool).
12-31 16:01:05.095 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.VisualElement:ChangeVisualStateInternal ().
12-31 16:01:05.096 20128 20128 D Mono    : AOT: FOUND method Microsoft.Maui.Controls.Button:ChangeVisualState () [0x70ca9961aad0 - 0x70ca9961ab35 0x70ca99703529]
12-31 16:01:05.096 20128 20128 D Mono    : AOT: FOUND method Microsoft.Maui.Controls.Button:get_IsPressed () [0x70ca9961a550 - 0x70ca9961a5c4 0x70ca997034c7]
12-31 16:01:05.096 20128 20128 D Mono    : AOT: FOUND method Microsoft.Maui.Controls.VisualStateManager:GoToState (Microsoft.Maui.Controls.VisualElement,string) [0x70ca9967fee0 - 0x70ca996803f1 0x70ca99708d38]
12-31 16:01:05.096 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:Microsoft.Maui.Controls.Internals.IButtonElement.PropagateUpPressed ().
12-31 16:01:05.096 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:Microsoft.Maui.Controls.Internals.IButtonElement.PropagateUpPressed ().
12-31 16:01:05.097 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Window:Microsoft.Maui.IPlatformEventsListener.DispatchTouchEvent (Android.Views.MotionEvent).
12-31 16:01:05.099 20128 20128 D monodroid-assembly: typemap: MVID [01128D64-8BBC-4364-AB86-D1D7C3E658F9] maps to assembly Mono.Android, looking for token 33555483 (0x200041b), table index 1051
12-31 16:01:05.099 20128 20128 D monodroid-assembly: typemap: type with token 33555483 (0x200041b) in module {01128D64-8BBC-4364-AB86-D1D7C3E658F9} (Mono.Android) corresponds to Java type 'java/lang/Object'
12-31 16:01:05.099 20128 20128 I DOTNET  :   Debug: Android: Unable to find click target. No breadcrumb captured.
12-31 16:01:05.099 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:Microsoft.Maui.IButton.Released ().
12-31 16:01:05.099 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:Microsoft.Maui.IButton.Released ().
12-31 16:01:05.100 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:SendReleased ().
12-31 16:01:05.100 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.ButtonElement:ElementReleased (Microsoft.Maui.Controls.VisualElement,Microsoft.Maui.Controls.Internals.IButtonElement).
12-31 16:01:05.100 20128 20128 D Mono    : AOT: FOUND method Microsoft.Maui.Controls.View:ChangeVisualState () [0x70ca99676290 - 0x70ca996762f0 0x70ca9970835e]
12-31 16:01:05.101 20128 20128 D Mono    : AOT: FOUND method Microsoft.Maui.Controls.VisualElement:ChangeVisualState () [0x70ca9967a440 - 0x70ca9967a4f8 0x70ca99708795]
12-31 16:01:05.101 20128 20128 D Mono    : AOT: FOUND method Microsoft.Maui.Controls.VisualElement:get_IsFocused () [0x70ca99678060 - 0x70ca996780d4 0x70ca99708578]
12-31 16:01:05.101 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:Microsoft.Maui.Controls.Internals.IButtonElement.PropagateUpReleased ().
12-31 16:01:05.101 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:Microsoft.Maui.Controls.Internals.IButtonElement.PropagateUpReleased ().
12-31 16:01:05.114 20128 20128 D Mono    : AOT: NOT FOUND: Android.Views.View/IOnClickListenerInvoker:n_OnClick_Landroid_view_View_ (intptr,intptr,intptr).
12-31 16:01:05.115 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Handlers.ButtonHandler/ButtonClickListener:OnClick (Android.Views.View).
12-31 16:01:05.115 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Handlers.ButtonHandler/ButtonClickListener:OnClick (Android.Views.View).
12-31 16:01:05.116 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Handlers.ButtonHandler:OnClick (Microsoft.Maui.IButton,Android.Views.View).
12-31 16:01:05.117 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:Microsoft.Maui.IButton.Clicked ().
12-31 16:01:05.117 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:Microsoft.Maui.IButton.Clicked ().
12-31 16:01:05.119 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:SendClicked ().
12-31 16:01:05.119 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.ButtonElement:ElementClicked (Microsoft.Maui.Controls.VisualElement,Microsoft.Maui.Controls.Internals.IButtonElement).
12-31 16:01:05.120 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:Microsoft.Maui.Controls.Internals.IButtonElement.PropagateUpClicked ().
12-31 16:01:05.120 20128 20128 D Mono    : AOT: NOT FOUND: Microsoft.Maui.Controls.Button:Microsoft.Maui.Controls.Internals.IButtonElement.PropagateUpClicked ().
12-31 16:01:05.121 20128 20128 D Mono    : AOT: FOUND method MauiAppSegfault.MainPage:Button_OnClicked (object,System.EventArgs) [0x70cb2eca26f0 - 0x70cb2eca2aab 0x70cb2eca384e]
12-31 16:01:05.121 20128 20128 D Mono    : AOT: NOT FOUND: Android.Util.Log:Info (string,string).
12-31 16:01:05.121 20128 20128 D Mono    : AOT: NOT FOUND: Android.Util.Log:Info (string,string).
12-31 16:01:05.121 20128 20128 D Mono    : Running class .cctor for Android.Util.Log from 'Mono.Android'
12-31 16:01:05.121 20128 20128 D Mono    : AOT: NOT FOUND: Android.Util.Log:.cctor ().
12-31 16:01:05.123 20128 20128 I MauiAppSegFault: Button_OnClicked
12-31 16:01:05.123 20128 20128 I sentry-native: entering signal handler
12-31 16:01:05.123 20128 20128 D sentry-native: defer to runtime signal handler at start
12-31 16:01:05.123 20128 20128 D sentry-native: return from runtime signal handler, we handle the signal
12-31 16:01:05.127 20128 20161 D EGL_emulation: app_time_stats: avg=997.77ms min=1.79ms max=12884.96ms count=13
12-31 16:01:05.129 20128 20128 D sentry-native: captured backtrace from ucontext with 2 frames
12-31 16:01:05.129 20128 20128 D sentry-native: captured backtrace with 2 frames
12-31 16:01:05.129 20128 20128 D sentry-native: merging scope into event
12-31 16:01:05.129 20128 20128 D sentry-native: trying to read modules from /proc/self/maps
12-31 16:01:05.215 20128 20128 D sentry-native: read 419 modules from /proc/self/maps
12-31 16:01:05.216 20128 20128 D sentry-native: adding attachments to envelope
12-31 16:01:05.216 20128 20128 D sentry-native: sending envelope
12-31 16:01:05.216 20128 20128 I sentry-native: crash has been captured
--------- beginning of crash
12-31 16:01:05.216 20128 20128 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x10 in tid 20128 (mauiappsegfault), pid 20128 (mauiappsegfault)
12-31 16:01:05.248 20188 20188 E crash_dump64: failed to get the guest state header for thread 20128: Bad address
12-31 16:01:05.249 20188 20188 E crash_dump64: failed to get the guest state header for thread 20129: Bad address
12-31 16:01:05.249 20188 20188 E crash_dump64: failed to get the guest state header for thread 20130: Bad address
12-31 16:01:05.249 20188 20188 E crash_dump64: failed to get the guest state header for thread 20131: Bad address
12-31 16:01:05.249 20188 20188 E crash_dump64: failed to get the guest state header for thread 20132: Bad address
12-31 16:01:05.249 20188 20188 E crash_dump64: failed to get the guest state header for thread 20133: Bad address
12-31 16:01:05.250 20188 20188 E crash_dump64: failed to get the guest state header for thread 20134: Bad address
12-31 16:01:05.250 20188 20188 E crash_dump64: failed to get the guest state header for thread 20135: Bad address
12-31 16:01:05.251 20188 20188 E crash_dump64: failed to get the guest state header for thread 20136: Bad address
12-31 16:01:05.255 20188 20188 E crash_dump64: failed to get the guest state header for thread 20137: Bad address
12-31 16:01:05.255 20188 20188 E crash_dump64: failed to get the guest state header for thread 20138: Bad address
12-31 16:01:05.255 20188 20188 E crash_dump64: failed to get the guest state header for thread 20140: Bad address
12-31 16:01:05.256 20188 20188 E crash_dump64: failed to get the guest state header for thread 20142: Bad address
12-31 16:01:05.256 20188 20188 E crash_dump64: failed to get the guest state header for thread 20143: Bad address
12-31 16:01:05.256 20188 20188 E crash_dump64: failed to get the guest state header for thread 20144: Bad address
12-31 16:01:05.256 20188 20188 E crash_dump64: failed to get the guest state header for thread 20148: Bad address
12-31 16:01:05.256 20188 20188 E crash_dump64: failed to get the guest state header for thread 20149: Bad address
12-31 16:01:05.257 20188 20188 E crash_dump64: failed to get the guest state header for thread 20150: Bad address
12-31 16:01:05.257 20188 20188 E crash_dump64: failed to get the guest state header for thread 20151: Bad address
12-31 16:01:05.257 20188 20188 E crash_dump64: failed to get the guest state header for thread 20152: Bad address
12-31 16:01:05.258 20188 20188 E crash_dump64: failed to get the guest state header for thread 20156: Bad address
12-31 16:01:05.258 20188 20188 E crash_dump64: failed to get the guest state header for thread 20157: Bad address
12-31 16:01:05.259 20188 20188 E crash_dump64: failed to get the guest state header for thread 20158: Bad address
12-31 16:01:05.259 20188 20188 E crash_dump64: failed to get the guest state header for thread 20159: Bad address
12-31 16:01:05.260 20188 20188 E crash_dump64: failed to get the guest state header for thread 20161: Bad address
12-31 16:01:05.260 20188 20188 E crash_dump64: failed to get the guest state header for thread 20164: Bad address
12-31 16:01:05.261 20188 20188 E crash_dump64: failed to get the guest state header for thread 20165: Bad address
12-31 16:01:05.261 20188 20188 E crash_dump64: failed to get the guest state header for thread 20166: Bad address
12-31 16:01:05.262 20188 20188 E crash_dump64: failed to get the guest state header for thread 20171: Bad address
12-31 16:01:05.262 20188 20188 E crash_dump64: failed to get the guest state header for thread 20172: Bad address
12-31 16:01:05.262 20188 20188 E crash_dump64: failed to get the guest state header for thread 20174: Bad address
12-31 16:01:05.263 20188 20188 E crash_dump64: failed to get the guest state header for thread 20175: Bad address
12-31 16:01:05.264 20188 20188 E crash_dump64: failed to get the guest state header for thread 20187: Bad address
12-31 16:01:05.275 20188 20188 I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstoneProto
12-31 16:01:05.275   219   219 I tombstoned: received crash request for pid 20128
12-31 16:01:05.276 20188 20188 I crash_dump64: performing dump of process 20128 (target tid = 20128)
12-31 16:01:05.439 20188 20188 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
12-31 16:01:05.439 20188 20188 F DEBUG   : Build fingerprint: 'google/sdk_gphone64_x86_64/emu64xa:15/AE3A.240806.005/12228598:user/release-keys'
12-31 16:01:05.439 20188 20188 F DEBUG   : Revision: '0'
12-31 16:01:05.440 20188 20188 F DEBUG   : ABI: 'x86_64'
12-31 16:01:05.440 20188 20188 F DEBUG   : Timestamp: 2024-12-31 16:01:05.282841700-0500
12-31 16:01:05.440 20188 20188 F DEBUG   : Process uptime: 16s
12-31 16:01:05.440 20188 20188 F DEBUG   : Cmdline: com.companyname.mauiappsegfault
12-31 16:01:05.440 20188 20188 F DEBUG   : pid: 20128, tid: 20128, name: mauiappsegfault  >>> com.companyname.mauiappsegfault <<<
12-31 16:01:05.440 20188 20188 F DEBUG   : uid: 10228
12-31 16:01:05.440 20188 20188 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000010
12-31 16:01:05.440 20188 20188 F DEBUG   : Cause: null pointer dereference
12-31 16:01:05.440 20188 20188 F DEBUG   :     rax 0000000000000010  rbx 000070cb48c66c30  rcx 000070cdfaefc018  rdx 0000000000000006
12-31 16:01:05.440 20188 20188 F DEBUG   :     r8  0000000000000000  r9  0000000000000000  r10 0000000000000002  r11 000070cb35491550
12-31 16:01:05.440 20188 20188 F DEBUG   :     r12 0000000000000007  r13 000070ca40102810  r14 000070caa15210d8  r15 000070caa151ed80
12-31 16:01:05.440 20188 20188 F DEBUG   :     rdi 0000000000000000  rsi 0000000000000600
12-31 16:01:05.440 20188 20188 F DEBUG   :     rbp 00007ffe888c0370  rsp 00007ffe888c0188  rip 000070caa3dd3430
12-31 16:01:05.440 20188 20188 F DEBUG   : 2 total frames
12-31 16:01:05.440 20188 20188 F DEBUG   : backtrace:
12-31 16:01:05.440 20188 20188 F DEBUG   :       #00 pc 00000000001d0430  /data/app/~~tGKhY7D7sBtvXZCZvJ4ECg==/com.companyname.mauiappsegfault-mxjQjPCIObrlYwmyztc-7Q==/lib/x86_64/libmonosgen-2.0.so (BuildId: 37021294544f624d009dfa77e9b7297559f13344)
12-31 16:01:05.440 20188 20188 F DEBUG   :       #01 pc 0000000000004744  /data/app/~~tGKhY7D7sBtvXZCZvJ4ECg==/com.companyname.mauiappsegfault-mxjQjPCIObrlYwmyztc-7Q==/lib/x86_64/libaot-MauiAppSegfault.dll.so
12-31 16:01:05.455   219   219 E tombstoned: Tombstone written to: tombstone_14

Issue does not occur in DEBUG config

Disabling both AOT & trimming via the below properties has no affect:

<PublishTrimmed>false</PublishTrimmed>
<PublishAot>false</PublishAot>
<RunAOTCompilation>false</RunAOTCompilation>

Issue does not occur if offending code explicitly throws NullReferenceException

-  var s = default(string);
-  var c = s.Length;
+  throw new NullReferenceException();

Issue does not occur if EnableNdk = false

SentrySdk.Init(options =>
{
  options.Dsn = Dsn;
  options.Debug = true;
+  options.Native.EnableNdk = false;
});

msbuild.binlog.zip

bruno-garcia · 2025-01-02T15:13:50Z

Thanks for the details. I recall seeing this odd behavior where a throw new NullRef doesn't raise errors but an actual null ref does. iirc it was due to how Mono deals with signals and convert stuff into C# exceptions (or not) and since our sdk captured errors via signal handler we report stuff Mono suppresses the crash of.

perhaps we need to let Mono do its thing before we take the signal handler. So instead of going first and calling the original handler we invert that

jamescrosswell · 2025-01-06T00:00:48Z

I think it relates to this change:

fix: Android - make sure logcat.log is attached to unhandled event (SIGSEGV Segfault) #3694

The underlying reason we made that changes is detailed here:

SIGSEGV reported by Sentry when a NullReferenceException is thrown in Release mode dotnet/android#9055 (comment)

I can't immediately think of an alternative way around this.

When a NullReferenceException is thrown and captured by the .NET SDK, we'd need some way for the managed signal handler to communicate to the NDK that the exception was already handled. @supervacuus do you know if there's some way for the .NET SDK to terminate a signal if it's already been handled? I would have assumed that kind of detail would be handled by the .NET Runtime.

BTW: Apologies for this making it into the 5.0.0 release. More testing should have been done on this PR before it was merged.

supervacuus · 2025-01-06T11:26:24Z

When a NullReferenceException is thrown and captured by the .NET SDK, we'd need some way for the managed signal handler to communicate to the NDK that the exception was already handled. @supervacuus do you know if there's some way for the .NET SDK to terminate a signal if it's already been handled? I would have assumed that kind of detail would be handled by the .NET Runtime.

The .NET runtime has no idea that another signal handler was installed after its own, similar to how the Native SDK signal handler has no idea it is running with CLR/Mono. So, the runtime can't really handle that detail because it expects to be the sole signal handler user in a .NET application (which, for most scenarios, is probably true) and uses it for the optimized path of code generation.

We can only provide heuristics in finding discriminators between the crashes we must handle in the Native SDK and the ones we should ignore. In August, I created the draft PR to allow downstream tests to validate a heuristic, which we know works for CLR on Linux, also for Mono on Android. Now we know that it doesn't work, and sadly, this had to be discovered by users rather than us.

This testing didn't happen in a way sufficient RE: the base case coming from the users. Since I was not involved in any downstream testing, I can only guess that most of it happened against Debug builds, where this issue does not surface (while with CLR on Linux, it does).

What is visible from the logs and also my own initial Maui experiments:

The assumption that the Mono signal handler on Android doesn't return if the signal converts to a managed code exception does not hold. This could be a general Mono thing, but it could also be specific to the implementation on Android. However, similar to CLR, it uses the signal handler to convert managed exceptions from SIGSEGV for optimized code paths (although that code is currently only generated in Release builds).
Returning from the signal handler even when the signal was a managed exception leaves us, even if we chain at the beginning of the signal handler, acting like it was a normal native crash.
In this scenario, when we reach the end of our signal handler, we continue the signal chain created via libsigchain on Android because that is the behavior we normally want for a native crash (creating a tombstone, letting debuggerd logcat a crash summary, etc.) and that now leads to the appearance of a crash.

To be clear, this is only from what I see in the logs. It is yet unclear why the signal handler behaves this way and whether this is generally the case with Mono, or specific to its implementation on Android. With CLR on Linux, the runtime signal handler never returns if it successfully converted a signal to a managed exception so that we can rely on that discontinuation of the signal chain as a signifier for a managed exception rather than a native crash. It is clear now that this is not the behavior for Mono on Android.

Last but not least, for me to dive any deeper here, we need to clarify this topic's ownership. I can handle this topic end-to-end, if necessary, if only from an available resource or expertise perspective. However, this should be explicitly decided and accordingly prioritized against all other things, which, to my knowledge, hasn't happened yet. Having a more principled approach here might be the right choice because it also affects the sentry-cocoa integration, although it is unclear whether there is any overlap between the required solutions.

jamescrosswell · 2025-01-06T22:58:29Z

Last but not least, for me to dive any deeper here, we need to clarify this topic's ownership. I can handle this topic end-to-end, if necessary, if only from an available resource or expertise perspective. However, this should be explicitly decided and accordingly prioritized against all other things, which, to my knowledge, hasn't happened yet.

I don't have enough context to be able to do that... I'm familiar with the dotnet backlog but not that of the NDK or Sentry, so can't say how this compares to other stuff on your plate.

For .NET at least, we're getting quite a few issues raised about SIGSEGV errors on iOS/Android so wrt .NET this one would be "High Impact".

I can reverse the order in which the signal handlers get chained easily enough in the .NET SDK. That will get us back to the original behaviour (so users' apps aren't crashing because of Sentry).

I'm currently the only developer maintaining the .NET SDK so any assistance beyond that (addressing the original issue) would be awesome. I'm definitely happy for you to own this if you have capacity.

supervacuus · 2025-01-07T07:41:40Z

I can reverse the order in which the signal handlers get chained easily enough in the .NET SDK. That will get us back to the original behaviour (so users' apps aren't crashing because of Sentry).

It might be sensible to disable the native crash reporters on Android and iOS for Maui as a first step so as not to double-report.

I'm currently the only developer maintaining the .NET SDK so any assistance beyond that (addressing the original issue) would be awesome. I'm definitely happy for you to own this if you have capacity.

I am (now) fully aware of the current resource situation. We will find a solution; I am currently not working on fixing this, and prioritization is out of my hands. We will plan how to move forward in the upcoming weekly.

jamescrosswell · 2025-01-08T22:41:49Z

The issue reported in this ticket (NullReferenceException causing app crashes on Android) has been resolved in:

Revert signal handler chaining order (PR #3694) #3871

The fix is included in the 5.0.1 release.

That leaves us with the original behaviour from 4.0.0, but still searching for an (alternate) resolution to the following issues on Android:

... and this, which is potentially related, on iOS:

Sentry reports handled NRE as EXC_BAD_ACCESS signal #3776

tranb3r · 2025-01-09T07:36:48Z

Original issue is this one:
dotnet/android#9055

jamescrosswell · 2025-01-09T10:34:20Z

Possibly useful: C++ source code for signal handling in the dotnet runtime.

It looks like the .NET runtime will invoke any previously registered signal handlers only if/when it doesn't explicitly handle the signal.

supervacuus · 2025-01-09T10:52:36Z

This will only happen if the Platform Adaptation Layer (PAL) hasn't been initialized yet so that the platform default handler handles SIGSEGVs happening before or during initialization.

supervacuus · 2025-01-09T10:59:49Z

Possibly useful: C++ source code for signal handling in the dotnet runtime.

I have already gone into analyzing the behavior of the CoreCLR implementation here: dotnet/android#9055 (comment). The question now is why the Mono on Android implementation behaves differently.

kahest · 2025-01-13T10:39:51Z

We don't have the required resources available on the Native team to solve this end-to-end at the moment, so coming back to #3861 (comment), we need to recommend deactivating the native crash reporters on Android and iOS for MAUI for the time being to mitigate the issue of duplicate reports.

However we're in the process of getting more resources on the downstream team(s) which means we'll hopefully be able to tackle the root cause some time in the next few months.

jamescrosswell · 2025-01-16T22:35:08Z

Since this issue (the application crashing) has been resolved, I'll close it.

I've opened a new issue summarising the remaining problem and steps we need to take to resolve in:

Managed NullReferenceException causes SIGSEGV errors on iOS and Android #3902

github-project-automation bot added this to GDX Dec 20, 2024

getsantry bot added the Waiting for: Product Owner label Dec 20, 2024

getsantry bot added this to GitHub Issues with 👀 3 Dec 20, 2024

getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Dec 20, 2024

tranb3r mentioned this issue Dec 20, 2024

SIGSEGV reported by Sentry when a NullReferenceException is thrown in Release mode dotnet/android#9055

Open

getsantry bot removed the Waiting for: Product Owner label Dec 23, 2024

getsantry bot removed the status in GitHub Issues with 👀 3 Dec 23, 2024

bruno-garcia added Bug Something isn't working Framework: MAUI labels Dec 23, 2024

getsantry bot added the Waiting for: Product Owner label Dec 31, 2024

getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Dec 31, 2024

getsantry bot removed the Waiting for: Product Owner label Jan 2, 2025

getsantry bot removed the status in GitHub Issues with 👀 3 Jan 2, 2025

getsantry bot added the Waiting for: Product Owner label Jan 6, 2025

getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Jan 6, 2025

getsantry bot removed the Waiting for: Product Owner label Jan 6, 2025

getsantry bot removed the status in GitHub Issues with 👀 3 Jan 6, 2025

getsantry bot added the Waiting for: Product Owner label Jan 7, 2025

getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Jan 7, 2025

jamescrosswell mentioned this issue Jan 7, 2025

Revert signal handler chaining order (PR #3694) #3871

Merged

bitsandfoxes removed the Waiting for: Product Owner label Jan 7, 2025

getsantry bot removed the status in GitHub Issues with 👀 3 Jan 7, 2025

getsantry bot added the Waiting for: Product Owner label Jan 9, 2025

getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Jan 9, 2025

bruno-garcia removed the Waiting for: Product Owner label Jan 9, 2025

getsantry bot removed the status in GitHub Issues with 👀 3 Jan 9, 2025

getsantry bot added the Waiting for: Product Owner label Jan 9, 2025

getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Jan 9, 2025

bitsandfoxes removed the Waiting for: Product Owner label Jan 13, 2025

getsantry bot removed the status in GitHub Issues with 👀 3 Jan 13, 2025

jamescrosswell mentioned this issue Jan 16, 2025

Managed NullReferenceException causes SIGSEGV errors on iOS and Android #3902

Open

jamescrosswell closed this as completed Jan 16, 2025

github-project-automation bot moved this to Done in GDX Jan 16, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SIGSEGV when a NullReferenceException is thrown in Release mode #3861

SIGSEGV when a NullReferenceException is thrown in Release mode #3861

tranb3r commented Dec 20, 2024 •

edited

Loading

bruno-garcia commented Dec 23, 2024

phunkeler commented Dec 31, 2024

bruno-garcia commented Jan 2, 2025

jamescrosswell commented Jan 6, 2025

supervacuus commented Jan 6, 2025

jamescrosswell commented Jan 6, 2025

supervacuus commented Jan 7, 2025

jamescrosswell commented Jan 8, 2025

tranb3r commented Jan 9, 2025

jamescrosswell commented Jan 9, 2025

supervacuus commented Jan 9, 2025

supervacuus commented Jan 9, 2025

kahest commented Jan 13, 2025

jamescrosswell commented Jan 16, 2025

SIGSEGV when a NullReferenceException is thrown in Release mode #3861

SIGSEGV when a NullReferenceException is thrown in Release mode #3861

Comments

tranb3r commented Dec 20, 2024 • edited Loading

Package

.NET Flavor

.NET Version

OS

SDK Version

Self-Hosted Sentry Version

Steps to Reproduce

Expected Result

Actual Result

Related issues/PRs

bruno-garcia commented Dec 23, 2024

phunkeler commented Dec 31, 2024

bruno-garcia commented Jan 2, 2025

jamescrosswell commented Jan 6, 2025

supervacuus commented Jan 6, 2025

jamescrosswell commented Jan 6, 2025

supervacuus commented Jan 7, 2025

jamescrosswell commented Jan 8, 2025

tranb3r commented Jan 9, 2025

jamescrosswell commented Jan 9, 2025

supervacuus commented Jan 9, 2025

supervacuus commented Jan 9, 2025

kahest commented Jan 13, 2025

jamescrosswell commented Jan 16, 2025

tranb3r commented Dec 20, 2024 •

edited

Loading