[POC] trap signals in threads and convert to handleable exceptions #2488
Conversation
…very Switch from the deprecated ucontext_t API to standard POSIX sigsetjmp/siglongjmp for converting SIGSEGV/SIGFPE signals to exceptions in SThread. Changes: - Remove ucontext.h include and platform-specific ucontext helpers - Remove trampoline function (no longer needed) - Add sigjmp_buf thread-local storage for recovery point - Signal handler now calls siglongjmp() instead of modifying ucontext - SThread uses sigsetjmp() to establish recovery point - Add SGetRecoveryPoint(), SSetRecoveryPointActive(), SBuildSignalException() APIs Benefits: - Uses standard POSIX API instead of deprecated ucontext - Simpler implementation (no trampoline needed) - Works on any POSIX system, not just Linux x86_64/ARM64 Tradeoff: - Destructors between fault and recovery point won't run (acceptable since thread is exiting anyway) Co-Authored-By: Claude Opus 4.5 <[email protected]>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c801111be3
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // Jump back to the recovery point set in SThread. | ||
| // The second argument becomes the return value of sigsetjmp. | ||
| siglongjmp(_SSignal_recoveryPoint, signum); |
There was a problem hiding this comment.
The recoverable path uses siglongjmp to escape the signal handler back to SThread. In C++, this bypasses stack unwinding for the faulting frame, so any RAII cleanup (mutex/lock_guard releases, SQLite transactions, socket state) held at the time of SIGSEGV/SIGFPE won’t run. If a recoverable signal hits while a lock or transaction is held in a socket handler, the thread exits but the lock can remain held, causing deadlocks or corrupted shared state while the server keeps running. This is a regression introduced by the new recovery path; consider restricting recovery to code that can tolerate skipping destructors or falling back to process termination instead.
Useful? React with 👍 / 👎.
Details
Fixed Issues
Fixes GH_LINK
Tests
Internal Testing Reminder: when changing bedrock, please compile auth against your new changes