Repository navigation
Prevent Native/Cocoa SDKs from capturing errors that also get captured by .NET #3954
Description
This would be the "long term solution" described in #3902 and the permanent resolution to the errors described in there:
However it likely requires support from the Native team and we don't currently have capacity to work on this (see #3861 (comment)).
Metadata
Metadata
Assignees
Projects
- Status
- Status
Activity
jurganson commentedon Mar 26, 2025
I'm facing an issue with duplicate logs in our Sentry implementation. While I've disabled native reports using options available in Sentry 5.3.0, my app still experiences significant native crashes that contain valuable information.
As a temporary workaround, I attempted to filter out unhelpful crashes by checking stack frames in
BeforeSend, specifically targetingsignalhandlermechanism crashes with no functions. However, during testing, I noticed that none of these native crashes went through myBeforeSendfunction.Is this expected behavior for native crashes to bypass
BeforeSend? I was testing on Sentry version 5.1.0, which may be relevant.jamescrosswell commentedon Mar 26, 2025
Support for native BeforeSend was introduced for iOS (#3958) in Version 5.3.0.
This has been available on Android since well before version 5.0.0 but is guarded by a flag in the options:
sentry-dotnet/src/Sentry/Platforms/Android/NativeOptions.cs
Line 262 in a621f42
There's another option for Android that you can use to suppress SIGSEGV native errors (
options.Android.SuppressSegfaults). Enabling that though will suppress native exceptions that are otherwise/already reported as a managedNullRefrenceException, however it can also suppress SIGSEGV errors unrelated to managed code (in which case you wouldn't know about quite serious bugs that were crashing your app).arek-corp commentedon Apr 16, 2025
Does the feature implemented in 5.5.0 for IScopeObserver help in this?
PR:
#4026
jamescrosswell commentedon Apr 16, 2025
It doesn't no. That PR is dealing with something unrelated.
92 remaining items
espenrl commentedon Apr 17, 2026
Awesome work @jpnurmi - I've been curiously reading many of the PR that went into this across repositories in Sentry dotnet/java/cocoa/native and dotnet android/macios/runtime for my own learning. There's alot of effort put into these so thanks for taking the time to solve a complicated problem.
jamescrosswell commentedon Apr 20, 2026
@jpnurmi can we finally close this issue or are we waiting for community feedback/confirmation?
jpnurmi commentedon Apr 21, 2026
Yes, this can now be closed. The last part of the fix for Android/CoreCLR shipped in 6.4.1. 🎉
[mono] Restore signal handlers during crash chaining (#125835)
[mono] Restore signal handlers during crash chaining (#125835)