[robobun]

Problem

• After unmodified signal-exit unloads, an app's SIGABRT listener is dead. The next SIGABRT ends Bun with exit 134. Node runs the listener.
• onDidChangeListeners (src/jsc/bindings/BunProcess.cpp) installs the OS handler per number and removes it per event name. SIGIOT is SIGABRT, so the last SIGIOT listener takes the handler with it. Bun__onSignalForJS emits one name per number, so no SIGIOT listener runs.
• On Linux, process.kill throws ERR_UNKNOWN_SIGNAL (Unknown signal: SIGPOLL) for SIGPOLL, SIGSTKFLT and SIGPWR, and process.on ignores the first two. No user reported them.

Fix

• Add SIGSTKFLT, SIGPOLL, SIGPWR and SIGUNUSED (SIGSYS on musl and bionic), each under #ifdef.
• Bun__onSignalForJS runs the listeners of every name of a number, like Node's watcher per event name (signal.js). The OS handler stays until no name has a listener.
• Verified: test/js/node/process/process-signal-listener-count.test.ts (19 new tests, 15 fail without the fix) and a new case in test/cli/watch/watch.test.ts. Also Node's test-signal-*, test-process-kill-*, test-watch-mode-kill-signal-*.
• Self-reviewed: 12 concerns raised, 8 addressed, 4 named in the notes. A later self-review moved SIGPWR here.

Background

• process.on(<signal name>) installs a sigaction handler that queues the number. The event loop then calls Bun__onSignalForJS to emit the event.
• On Linux, JSC suspends threads with SIGPWR, so process.on("SIGPWR") installs no OS handler. A new test reads the handler with sigaction(2). Before Bump WebKit to 63a807e88ce0: cheaper embedded-bytecode decode and CodeBlock linking #43616, a SIGPWR from process.kill crashed the process. Now JSC drops it.

Downsides

• With signal-exit loaded, an app SIGABRT listener runs twice for one SIGABRT. Node does the same.
• process.kill(process.pid, "SIGPWR") threw ERR_UNKNOWN_SIGNAL. Now it returns true and JSC drops the signal. Node runs the SIGPWR listener (see Bump WebKit: a SIGPWR that JSC did not send no longer crashes the process #43213).

Notes

Related: #12918 (signal-exit on a normal exit). Not fixed here. The signal-exit versions checked are 3.0.7 and 4.1.0.

signal-exit registers a listener for SIGABRT, SIGIOT, SIGIO, SIGPOLL, SIGSTKFLT, SIGUNUSED and more. Linux x64, Node v26.3.0, Bun 1.4.3-canary.1+367d939d9:

// teardown.cjs: an app listener, then signal-exit loads and unloads
const { onExit } = require("signal-exit"); // 3.0.7 exports the function itself
const keepAlive = setTimeout(() => {}, 5000);
process.on("SIGABRT", () => { console.log("app SIGABRT listener ran"); clearTimeout(keepAlive); });
onExit(() => {})(); // the returned function removes the last user, so signal-exit unloads
process.kill(process.pid, "SIGABRT");

	Node	Bun before	Bun after
teardown.cjs	listener runs, exit 0	Aborted (core dumped), exit 134	listener runs, exit 0

One visible change with signal-exit loaded next to an app SIGABRT listener: after the app listener, the SIGIOT listener of signal-exit now runs too. It is the only SIGIOT listener, so it calls onExit(null, "SIGIOT"), unloads and sends the signal again, and the app listener runs a second time. Node prints the same three lines. Bun before ran the app listener once.

process.kill(0x7ffffff0, name):

name	os.constants.signals	Node	Bun before	Bun after
SIGSTKFLT	16	ESRCH	ERR_UNKNOWN_SIGNAL	ESRCH
SIGPOLL	29	ESRCH	ERR_UNKNOWN_SIGNAL	ESRCH
SIGPWR	30	ESRCH	ERR_UNKNOWN_SIGNAL	ESRCH

One delivery of the signal. Each listener prints [event, name argument, number argument]:

sent	listeners	Node, and Bun after	Bun before
SIGSTKFLT	SIGSTKFLT	["SIGSTKFLT","SIGSTKFLT",16]	process.kill throws ERR_UNKNOWN_SIGNAL
SIGIO	SIGPOLL	["SIGPOLL","SIGPOLL",29]	the process dies with SIGIO
SIGIO	SIGIO, SIGPOLL	both run	only SIGIO runs
SIGABRT	SIGIOT	["SIGIOT","SIGIOT",6]	no listener runs
SIGABRT	SIGABRT, SIGIOT	both run	only SIGABRT runs

SIGPWR (added after the first review of this PR, on top of a merge of main for the WebKit of #43616):

const { spawn } = require("node:child_process");
const child = spawn("sleep", ["1000"], { stdio: "ignore" });
child.on("exit", (code, signal) => console.log("exit", code, signal));
process.kill(child.pid, "SIGPWR");

	Node	Bun before	Bun after
the script above	exit null SIGPWR	ERR_UNKNOWN_SIGNAL	exit null SIGPWR
--watch --watch-kill-signal SIGPWR with a SIGPWR listener	the listener gets ("SIGPWR", 30)	no listener call	the listener gets ("SIGPWR", 30)
process.kill(process.pid, "SIGPWR") with a listener	the listener runs	ERR_UNKNOWN_SIGNAL	the signal is dropped, the process continues

• The row in loadSignalNumberToNamesMap is needed for --watch-kill-signal SIGPWR. Without it, Bun__onSignalListenerCountChanged counts the listener, the reload goes through the event loop, and Bun__onSignalForJS(30) finds no name. The reload emits the event itself, so it needs no OS handler. The new watch.test.ts case fails without that row.
• The guard test reads sigaction(2) and runs no GC loop. A child with a SIGPWR listener that runs Bun.gc(true) many times proves nothing: an LD_PRELOAD shim that logs each pthread_kill(SIGPWR) shows 0 calls in 50 full collections, and a build without the sigThreadSuspendResume check passes it. A synchronous collection runs on the JS thread and suspends no thread.
• What does send SIGPWR in a debug build: the libpas scavenger (36 calls in 0.5 s under BUN_JSC_collectContinuously=1, to the HeapHelper, Collector Thread and Continuous GC threads) and the sampling profiler (72 calls to the JS thread in one profile() of 25 ms). On a build without the check, a child with a listener hangs at the first of these (the scavenger thread waits in WTF::Thread::suspend forever), and after process.off() it dies with Power failure, exit 158. Both depend on timers. So the test checks the invariant itself: the handler address is the same before process.on(), after it, and after process.off(). The build without the check gives keptByOn: false, keptByOff: false.
• With JSC_SIGNAL_FOR_GC=23, JSC does not use SIGPWR. Then process.on("SIGPWR") installs the handler, a self-sent SIGPWR runs the listener with ("SIGPWR", 30), and without a listener the process ends with exit 158. This is Node's behavior.
• The self-send test does not check whether the listener runs. It checks that process.kill returns true and that the process ends with exit 0. That stays true when a later change delivers the signal to the listener.
• src/jsc/bindings/c-bindings.cpp still keeps SIGPWR out of the spawnSync signal forwarding. That handler would replace JSC's.
• Found outside this PR: a process.kill error has errno: 3 and the message kill() failed: ESRCH: No such process. Node has errno: -3 and kill ESRCH. This is the same for every signal on main. I found no open PR for it.

Behavior details:

• Node runs the listeners of two names in libuv's handle order, which is not fixed. Bun runs them in table order (SIGABRT before SIGIOT). The tests do not depend on the order.
• A name that gets its first listener from a listener of the same delivery does not get the event for that delivery. Node has no watcher for it yet. Bun__onSignalForJS collects the names that have a listener before it emits.
• A listener that throws under one name does not stop the listeners of the other name. Node and Bun agree (checked with an uncaughtException handler).

Not done here:

• One table derived from os.constants.signals. It is a separate change. The new process.kill test reads os.constants.signals, so the hand tables cannot drift from it again.
• Node drains process.nextTick and microtasks between the two names, because each watcher is a separate callback. Bun emits both names in one task and drains after it. Node's order of the two names is not fixed, so a program cannot depend on this.
• bun run --watch mirrors the listener count of the --watch-kill-signal number to the watcher thread. That mirror now gets the count of all names of the number. It is the same value that decides the handler removal, which the tests cover. No test covers the watch mode path with two names.
• A Symbol event whose description is a signal name is a signal event for Bun, on main and with this change. process.on(Symbol("SIGIO"), f) followed by process.off(Symbol…, f) removes the OS handler under a real "SIGIO" listener (exit 157). Node ignores Symbol events here. This needs its own change.

Code details:

• The add(...) lines in loadSignalNumberToNamesMap change mechanically. HashMap::add keeps the first value of a key, so the old SIGIOT line had no effect.
• os.constants.signals comes from another table (ProcessBindingConstants.cpp), which already has these names.
• In the process.kill and process.on tables, SIGLOST is the name of Node's list that is still absent. No libc that Bun builds for defines SIGLOST.
• This change does not touch the Rust table bun_core::SignalCode (src/bun_core/Global.rs). Bun.spawn killSignal, subprocess.kill(name) and --watch-kill-signal read that table. spawn: name exit signals and send named signals with the platform's numbers #39970 named its slot 16 SIGSTKFLT. It still does not know SIGIOT, SIGPOLL or SIGUNUSED.
• On Linux, "SIGINFO" still maps to 255 in the name table (Node throws ERR_UNKNOWN_SIGNAL for it). This change keeps that behavior.
• Windows has no number with two names, so nothing changes there. The changed Windows-only line compiles (checked with a Windows x64 debug build).

Tests:

• Each new case runs in a child process. The child sends the signal under test to itself, and sends SIGUSR2 from setImmediate. The loop runs the listeners of the pending signal before it runs the immediate. So the SIGUSR2 listener prints the result after the listeners of the first signal ran, and the result does not depend on the order in which two pending numbers drain (Replace the pending-signal ring with one counter per signal number #41443 changes that order). A missing listener call fails the test at once, with no wait.
• Four of the 19 new tests pass without the fix. SIGIOT sent with a SIGABRT listener already worked. The two "listener added during the delivery" cases guard the new emit loop. The sigaction test guards the check in onDidChangeListeners that the SIGPWR row makes reachable.
• The "restores the default action" test uses SIGIO because its default action terminates without a core dump. The CI runner reports a new core file as a crash.
• The tests are not in process.test.js because that file has unrelated timeouts under a debug build.
• At ac211d5 (before the SIGPWR commit), CI ran the file on glibc, musl (26 tests with the SIGSYS and SIGUNUSED rows) and macOS (9 run, 4 skipped). The local runs also passed the signal block of process.test.js. Locally it passed 18 runs in a row on a loaded machine, 12 of them 6 at a time. BUN_JSC_validateExceptionChecks=1 reports nothing.
• process: accept SIGSTKFLT/SIGPOLL/SIGPWR by name and fire aliased signal listeners #33776 made the same change in July. A cleanup of stale PRs closed it unmerged.

---

no test proof · iteration 0 · platform-specific test(s) that do not run on this machine, deferring to CI, which covers all platforms: test/js/node/process/process-signal-listener-count.test.ts, test/cli/watch/watch.test.ts

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: oven-sh/bun/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Essentials

Run ID: 3e3c3e80-3003-4483-9a7b-16d799352383

📥 Commits

Reviewing files that changed from the base of the PR and between 26e7a4b and ac211d5.

📒 Files selected for processing (2)

• src/jsc/bindings/BunProcess.cpp
• test/js/node/process/process-signal-listener-count.test.ts

Included review availability: Your plan provides up to 10 included reviews per hour; 3 remain after this review.

---

Walkthrough

Signal handling now preserves aliases for shared signal numbers, dispatches events to listeners registered under each alias, aggregates listener counts, and supports additional platform-specific signal names. Tests cover alias behavior, listener changes, and default signal restoration.

Changes

Signal Alias Support

Layer / File(s)	Summary
Signal metadata and dispatch src/jsc/bindings/BunProcess.cpp	Signal mappings now retain multiple names per signal number, including SIGSTKFLT, SIGPOLL, and SIGUNUSED. Delivery emits events for each matching alias with listeners. Listener counts and OS handler registration aggregate aliases.
Signal alias validation test/js/node/process/process-signal-listener-count.test.ts	Tests cover signal recognition, alias dispatch, listener removal, listeners added during delivery, platform-specific aliases, and restoration of default signal actions.

Suggested reviewers: cirospaciari

Priority: ➖ Normal

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly summarizes the main changes: support for additional signal names and emission of all aliases for a signal number.
Description check	✅ Passed	The description explains the problem, fix, behavior changes, limitations, and verification results. It uses different headings from the template, but it provides equivalent content for both required s…

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

^{Updated 10:41 PM PT - Sep 21st, 2026}

✅ @robobun, your commit ef2151223b3454975c9355d56d176de9b1739e9b passed in Build #119563! 🎉

---

🧪   To try this PR locally:

bunx bun-pr 43500

That installs a local version of the PR into your bun-43500 executable, so you can run:

bun-43500 --bun

[robobun]

Status: fix pushed in this PR (#43500).

Reproduction (Linux x64, Bun 1.4.3-canary.1+367d939d9, Node v26.3.0 for comparison):

// repro.js
const os = require("os");
for (const name of ["SIGSTKFLT", "SIGPOLL", "SIGIO"]) {
  let result;
  try {
    result = String(process.kill(0x7ffffff0, name));
  } catch (e) {
    result = e.code;
  }
  console.log(name, os.constants.signals[name], result);
}

$ bun repro.js
SIGSTKFLT 16 ERR_UNKNOWN_SIGNAL
SIGPOLL 29 ERR_UNKNOWN_SIGNAL
SIGIO 29 ESRCH
$ node repro.js
SIGSTKFLT 16 ESRCH
SIGPOLL 29 ESRCH
SIGIO 29 ESRCH

The listener side, with one delivery of signal 6:

// alias.js
process.on("SIGIOT", (name, number) => console.log("listener", name, number));
const keepAlive = setTimeout(() => {}, 1000);
process.on("SIGUSR2", () => clearTimeout(keepAlive));
process.kill(process.pid, "SIGABRT");
process.kill(process.pid, "SIGUSR2");

$ node alias.js
listener SIGIOT 6
$ bun alias.js
$

The handler removal, with signal-exit 4.1.0 from npm:

// teardown.cjs
const { onExit } = require("signal-exit");
const keepAlive = setTimeout(() => {}, 5000);
process.on("SIGABRT", () => { console.log("app SIGABRT listener ran"); clearTimeout(keepAlive); });
onExit(() => {})(); // signal-exit loads, then unloads and removes its SIGABRT and SIGIOT listeners
process.kill(process.pid, "SIGABRT");

$ node teardown.cjs
app SIGABRT listener ran
$ bun teardown.cjs
Aborted (core dumped)        # exit 134

USE_SYSTEM_BUN=1 bun test test/js/node/process/process-signal-listener-count.test.ts fails 13 of the 16 new tests. bun bd test on the same file passes all 19.

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

[claude]

I reviewed the latest push and didn't find any bugs. Because this changes how process dispatches OS signals to listeners (a native, platform-gated path), a human look would still be worthwhile before merging.

What was reviewed:

• loadSignalNumberToNamesMap: the add lambda relies on HashMap::add returning the existing entry for a duplicate key, so SIGIOT appends to SIGABRT's vector rather than being dropped; the table indices 32-34 line up with the three new getSignalNames() entries in both maps.
• Bun__onSignalForJS: exceptions thrown by a listener are handled inside innerInvokeEventListeners, so a throwing SIGABRT listener does not skip the SIGIOT pass; listeners removed by user code between the collect and emit loops just make emitForBindings return false. The !fired && SIGINT watch-mode check in PosixSignalHandle.rs is unaffected since SIGINT has one name.
• listenerCountForSignal feeds both the signalToContextIdsMap teardown and the Bun__onSignalListenerCountChanged mirror, whose Rust consumer only compares the count to zero, so the aggregate count is safe there.
• The process.kill knows every name in os.constants.signals test: ProcessBindingConstants.cpp guards every entry with #ifdef and lists no name absent from the BunProcess.cpp table (apart from the excluded SIGPWR), so it should hold on macOS and musl as well as glibc.

Extended reasoning...

Overview

The PR touches src/jsc/bindings/BunProcess.cpp (the C++ process binding) and test/js/node/process/process-signal-listener-count.test.ts. It replaces the one-name-per-signal-number map with HashMap<int, Vector<String, 2>>, adds SIGSTKFLT, SIGPOLL and SIGUNUSED to the name table under #ifdef, emits the signal event under every alias that has a listener, and aggregates listener counts across aliases when deciding whether to install or remove the OS handler. Since my prior review the author pushed three commits: the process.kill test now checks every name in os.constants.signals instead of only the Linux-only names, the child sends its SIGUSR2 sentinel from setImmediate instead of back-to-back, and the comment in Bun__onSignalForJS was shortened.

Security risks

None specific to this change. The new code reads only static string tables and listener maps; no user-controlled data reaches a path or an allocation size. The only user JS that runs is the existing listener dispatch, whose reentrancy is handled by innerInvokeEventListeners copying the listener vector and holding a Ref<EventEmitter>.

Level of scrutiny

Medium. The diff is small (+226/-54) and mostly mechanical, but it changes signal-delivery semantics in native code with #ifdef-gated entries that only compile on some platforms, and it changes when the OS handler is uninstalled. The author states CI ran on glibc, musl and macOS and that a Windows debug build compiles; I could not run the test file here (the evidence note says the platform-specific tests do not run on this machine), so a maintainer who can confirm CI on all lanes should still look.

Other factors

I verified the pieces most likely to hide a regression: HashMap::add's keep-first semantics are what make the add lambda append aliases correctly; the emit loop tolerates listeners that throw or remove other listeners mid-dispatch; Bun__onSignalListenerCountChanged's consumer in PosixSignalHandle.rs only compares the count to zero, so aggregating across aliases does not change its behaviour; and the os.constants.signals table in ProcessBindingConstants.cpp does not contain any name that BunProcess.cpp's name-to-number map lacks, so the new process.kill test should hold on every non-Windows lane. The reserveInitialCapacity(31) on the names map is only a hint and the map grows as needed. The one inline note from my earlier review was pre-existing and non-blocking, and the PR notes explicitly scope the Rust SignalCode table out of this change. The hunt ran to a dry streak with no findings.

[robobun]

Merge order with #43613: merge #43613 before this PR, or together with it.

• This PR makes Bun__onSignalForJS run the listeners of every name of a number. A listener added as process.on("SIGIOT") then runs when signal 6 arrives.
• A program that forwards each signal with process.on(name, () => subprocess.kill(name)) then calls subprocess.kill("SIGIOT"). Without spawn: accept every signal name in os.constants.signals #43613 that call throws ERR_INVALID_ARG_TYPE, because the Rust table behind Bun.spawn does not know SIGIOT. On main the SIGIOT listener never runs, so that program works today.
• spawn: accept every signal name in os.constants.signals #43613 makes kill("SIGIOT") send 6. I applied both changes to one Linux debug build: the forwarder runs the SIGABRT and the SIGIOT listener and both kill() calls succeed, process-signal-listener-count.test.ts passes (19), and the tests of spawn: accept every signal name in os.constants.signals #43613 pass.

The two PRs share no file. One more case passes only with both: bun --watch --watch-kill-signal SIGIOT runs a listener added as process.on("SIGIOT") before the reload. The PR that merges second can add that test.

[robobun]

I pushed two commits to this branch. They add SIGPWR, the last name of os.constants.signals that process.kill refused.

• e23a0c6 merges main. The branch was older than the WebKit bump of Bump WebKit to 63a807e88ce0: cheaper embedded-bytecode decode and CodeBlock linking #43616. Without that WebKit, a SIGPWR from process.kill crashes the process, which is why this PR first left the name out. The merge had no conflicts.
• ef21512 adds SIGPWR to getSignalNames() (index 35) and to both tables, under #ifdef SIGPWR. The process.kill knows every name in os.constants.signals test no longer skips the name.

process.on("SIGPWR") still installs no OS handler on Linux, because JSC suspends threads with that signal. onDidChangeListeners already skips it. A new test reads the handler with sigaction(2) before process.on(), after it, and after process.off(). A build without that check in onDidChangeListeners fails the test.

The row in the number-to-name table is needed for bun --watch --watch-kill-signal SIGPWR. The reload emits the event itself, so the SIGPWR listeners now run before the restart, as in Node. test/cli/watch/watch.test.ts has a new case for it.

Local results on a debug build (Linux x64): process-signal-listener-count.test.ts 22 pass, and 15 of them fail with the src/ of main. watch.test.ts 16 pass, and the new case fails with the src/ of main. I updated the title and the body. The notes in the body have the details.

[claude]

I re-reviewed the latest push (the SIGPWR-by-name commit and the main merge) and found no bugs; since it widens the scope the earlier notes on this PR did not cover, a human look at that part is still worthwhile.

What was reviewed on this push:

• SIGPWR registration on Linux: onDidChangeListeners still mirrors the count to Bun__onSignalListenerCountChanged before the sigThreadSuspendResume gate, so --watch-kill-signal SIGPWR takes the event-loop reload path while no forwarding handler is ever installed over JSC's.
• Watch reload calls Bun__onSignalForJS directly (no self-kill), so the new watch.test.ts case never routes a real SIGPWR through JSC's handler; process.kill(self, "SIGPWR") still skips the profile-flush only when a handler entry exists, which it never does for SIGPWR.
• Multi-name emit: innerInvokeEventListeners consumes listener exceptions itself, so a throwing SIGABRT listener leaves no pending exception before the SIGIOT emit; the Identifier snapshot holds refcounted strings, not GC cells, so re-entrant add/remove during a listener is safe.

Extended reasoning...

The diff changes src/jsc/bindings/BunProcess.cpp so a signal number maps to several event names (SIGABRT/SIGIOT, SIGIO/SIGPOLL, SIGSYS/SIGUNUSED), adds SIGSTKFLT, SIGPOLL, SIGUNUSED and, in the newest commit, SIGPWR to the name tables, emits every listened name per delivery, and sums listener counts across aliases before tearing down the OS handler; tests are added in process-signal-listener-count.test.ts and watch.test.ts. It touches no auth, crypto, or injection surface, but it is process-wide POSIX signal disposition logic with Linux-only behavior (JSC's SIGPWR thread-suspend handler) that the prior runs did not examine. Two commits landed since the last review, one of which reverses the PR's earlier decision to leave SIGPWR out, and the platform-specific tests could not be executed in this run, so this is not a mechanical change I can approve on my own.