fix(android): mask signal during CHAIN_AT_START to survive chained Mono handler re-raises

[jpnurmi]

Summary

• On Android, mask the signal before invoking the chained handler so SA_NODEFER doesn't let re-raises kill the process
• Use raw rt_sigprocmask syscall to bypass Android's libsigchain, whose sigprocmask guard is only active inside its own special handlers
• After the chain: reinstall our handler if it was reset to SIG_DFL, consume any pending signal via sigtimedwait, and unmask

Context

With SA_NODEFER, the chained Mono handler can reset the signal handler to SIG_DFL and re-raise. The re-raised signal is delivered immediately and kills the process before inproc can capture the crash.

This is gated to Android because only the Mono runtime (used on Android) does the reset+raise pattern. On desktop Linux, CoreCLR modifies the ucontext and returns without re-raising.

[supervacuus]

Mono's mono_handle_native_crash resets the crashing signal to SIG_DFL and re-raises it as part of its crash handling flow. With SA_NODEFER, the re-raised signal is delivered immediately

Yeah, this makes sense, but is there no Mono test in the downstream integration tests? It is quite painful that the two runtimes differ so severely, given that we seem to lack any early warning for that particular config. Or did this only happen with .NET 10?

Recursive crash detection (the reason SA_NODEFER was added) is not critical for CHAIN_AT_START because:

Not critical is an understatement. It is as critical as with all other use cases, when the signal actually comes from code that the Native SDK should handle.

Wouldn't it be better to just mask the incoming signal before we invoke the handler at start? This way, a raise inside the .NET handler is blocked until we sigreturn, and we retain the recursive reentrancy semantics of our handler (which are critical because we execute user-provided code from the handler). Disable the unmask once we know the .NET handler didn't feel responsible for the signal.

[jpnurmi]

Yeah, this makes sense, but is there no Mono test in the downstream integration tests? It is quite painful that the two runtimes differ so severely, given that we seem to lack any early warning for that particular config. Or did this only happen with .NET 10?

This happens with both .NET 9 and .NET 10. Unfortunately, the PR that takes chained signal handling into use and would have revealed this problem, has been on hold until now due to other issues in .NET 10.

• feat: native signal handler strategy on Android sentry-dotnet#4676

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}