fuzzilli: chain crash signal handlers to JSC/ASAN instead of SIG_DFL - #30092
Closed
robobun wants to merge 4 commits into
Closed
fuzzilli: chain crash signal handlers to JSC/ASAN instead of SIG_DFL#30092robobun wants to merge 4 commits into
robobun wants to merge 4 commits into
Claude / Claude Code Review
completed
May 2, 2026 in 13m 27s
Code review found 1 important issue
Found 8 candidates, confirmed 2. See review comments for details.
Details
| Severity | Count |
|---|---|
| 🔴 Important | 1 |
| 🟡 Nit | 1 |
| 🟣 Pre-existing | 0 |
| Severity | File:Line | Issue |
|---|---|---|
| 🔴 Important | src/bun.js/bindings/FuzzilliREPRL.cpp:291-294 |
Re-installing handlers per global object causes infinite recursion and loses JSC/ASAN chain |
| 🟡 Nit | src/bun.js/bindings/FuzzilliREPRL.cpp:58 |
SA_ONSTACK not set — stack-overflow SIGSEGV still yields bare TERMSIG 11 |
Annotations
Check failure on line 294 in src/bun.js/bindings/FuzzilliREPRL.cpp
claude / Claude Code Review
Re-installing handlers per global object causes infinite recursion and loses JSC/ASAN chain
`Bun__REPRL__registerFuzzilliFunctions()` is called from `Zig__GlobalObject__create` (ZigGlobalObject.cpp:518) for **every** global object — including Workers — so the first `new Worker(...)` re-runs `installFuzzilliSignalHandler()`, and `sigaction()` returns `fuzzilliSignalHandler` itself as the previous handler, overwriting `fuzzilliOldActions[sig]`. This permanently loses the saved JSC/ASAN chain (back to bare `TERMSIG: 11`) and makes any subsequent signal recurse infinitely into itself. Guar
Check warning on line 58 in src/bun.js/bindings/FuzzilliREPRL.cpp
claude / Claude Code Review
SA_ONSTACK not set — stack-overflow SIGSEGV still yields bare TERMSIG 11
Consider adding `SA_ONSTACK` here (`action.sa_flags = SA_SIGINFO | SA_ONSTACK`). ASAN/JSC set up a sigaltstack and install their SIGSEGV handlers with `SA_ONSTACK` so they can run when the fault is a stack overflow; without it, `fuzzilliSignalHandler` is delivered on the already-exhausted stack, immediately re-faults, and the process dies with a bare `TERMSIG: 11` — the symptom this PR is eliminating. Not a regression (the old `signal()` path also lacked it), but it's a one-token fix in code bei
Loading