You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Picking this up as a documentation task. Some context on how the landscape has shifted since this issue was filed, since SuppressSegfaults is no longer the only (or preferred) answer here.
The underlying problem — a single managed exception that surfaces as a native signal (e.g. a NullReferenceException raised as a SIGSEGV) gets captured twice: once as the managed .NET exception, once as a native crash. This is tracked in #3954.
The newer, preferred fix (@jpnurmi) reorders the signal handlers so the .NET runtime handles the managed exception first, preventing the duplicate at the source rather than suppressing the native signal:
iOS — automatic since 6.4.0; there is no SuppressSegfaults option on iOS.
Android — SignalHandlerStrategy.ChainAtStart is the preferred (experimental) fix; AndroidOptions.SuppressSegfaults (Suppress Native SIGSEGV signal errors on Android #3903) remains as a blunt fallback that suppresses SIGSEGV capture entirely (and can therefore hide genuine native segfaults).
Rather than documenting SuppressSegfaults in isolation, I've written this up as a "Duplicate events from native crashes" troubleshooting section that leads with the preferred fix per platform and keeps SuppressSegfaults as a documented Android fallback:
Closing here once that merges. Flagging in case anyone thinks SuppressSegfaults should instead be deprecated now that ChainAtStart exists.
+1 for leaving SuppressSegfaults available as an alternative option alongside ChainAtStart as long as they are needed. I guess we won't be able to get rid of them anytime soon because .NET 10 LTS surely will be supported for a good while, and dotnet/runtime#125835 won't be available until .NET 11 (v11.0.0-preview.5.26302.115). I wonder if we should try to request it to be cherry-picked into .NET 10... 🤔
Closing here once that merges. Flagging in case anyone thinks SuppressSegfaults should instead be deprecated now that ChainAtStart exists.
+1 for leaving SuppressSegfaults available as an alternative option alongside ChainAtStart as long as they are needed. I guess we won't be able to get rid of them anytime soon because .NET 10 LTS surely will be supported for a good while, and dotnet/runtime#125835 won't be available until .NET 11 (v11.0.0-preview.5.26302.115). I wonder if we should try to request it to be cherry-picked into .NET 10... 🤔
Not compatible with .NET runtimes 10.0.0–10.0.3 (.NET SDKs 10.0.100–10.0.103). On those versions, the SDK falls back to the default strategy automatically. This was fixed in .NET runtime 10.0.4 (.NET SDK 10.0.200).
Is the android fix not available until .NET 11 at the moment?
ChainAtStart docs look correct to me. Due to changes in .NET 10, ChainAtStart cannot be used with Mono in those few early .NET 10.0.0-10.0.3 versions. Other .NET versions are not impacted.
There's another Mono fix coming in .NET 11, that supercedes the short-term ChainAtStart fix and allows us to reorder the signal handlers properly (io.sentry.ndk.preload=true).
Activity
jamescrosswell commentedon Jul 2, 2026
Picking this up as a documentation task. Some context on how the landscape has shifted since this issue was filed, since
SuppressSegfaultsis no longer the only (or preferred) answer here.The underlying problem — a single managed exception that surfaces as a native signal (e.g. a
NullReferenceExceptionraised as aSIGSEGV) gets captured twice: once as the managed .NET exception, once as a native crash. This is tracked in #3954.The newer, preferred fix (@jpnurmi) reorders the signal handlers so the .NET runtime handles the managed exception first, preventing the duplicate at the source rather than suppressing the native signal:
options.Native.ExperimentalOptions.SignalHandlerStrategy = SignalHandlerStrategy.ChainAtStart(experimental), shipped in 6.4.0Default;ChainAtStartis only required on Mono), shipped in 6.4.1So the platform story is now:
SuppressSegfaultsoption on iOS.SignalHandlerStrategy.ChainAtStartis the preferred (experimental) fix;AndroidOptions.SuppressSegfaults(Suppress Native SIGSEGV signal errors on Android #3903) remains as a blunt fallback that suppressesSIGSEGVcapture entirely (and can therefore hide genuine native segfaults).Rather than documenting
SuppressSegfaultsin isolation, I've written this up as a "Duplicate events from native crashes" troubleshooting section that leads with the preferred fix per platform and keepsSuppressSegfaultsas a documented Android fallback:getsentry/sentry-docs#18623
Closing here once that merges. Flagging in case anyone thinks
SuppressSegfaultsshould instead be deprecated now thatChainAtStartexists.jpnurmi commentedon Jul 2, 2026
+1 for leaving
SuppressSegfaultsavailable as an alternative option alongsideChainAtStartas long as they are needed. I guess we won't be able to get rid of them anytime soon because .NET 10 LTS surely will be supported for a good while, and dotnet/runtime#125835 won't be available until .NET 11 (v11.0.0-preview.5.26302.115). I wonder if we should try to request it to be cherry-picked into .NET 10... 🤔jamescrosswell commentedon Jul 2, 2026
Did we get the docs wrong on this?
Is the android fix not available until .NET 11 at the moment?
jpnurmi commentedon Jul 3, 2026
ChainAtStartdocs look correct to me. Due to changes in .NET 10,ChainAtStartcannot be used with Mono in those few early .NET 10.0.0-10.0.3 versions. Other .NET versions are not impacted.There's another Mono fix coming in .NET 11, that supercedes the short-term
ChainAtStartfix and allows us to reorder the signal handlers properly (io.sentry.ndk.preload=true).Add troubleshooting section for duplicate native crash events (.NET) (#…