#37754 spawnSync: keep event-loop ref counts on the loop they were taken on

Problem

bun test --parallel workers intermittently stop inside Bun.spawnSync of a local bun child. In CI this is the flaky annotation "failed in the parallel batch ... passed alone": the batch goes quiet, the runner kills it after 4 minutes and prints Interrupted while still running: <file> (24xs), and the file passes in ~100ms on its own. The victims are whatever spawn-heavy files land in the batch (napi do.test.ts files, resolve.test.ts, child_process.test.ts, ctrl-c.test.ts, text-loader.test.ts, malformed-integrity-base64.test.ts, ...), across ubuntu, debian and alpine lanes (for example builds 92307, 92340, 92426, 92160). A second shape of the same failure is a run of consecutive tests in one worker each failing with killed 1 dangling process + this test timed out after 90000ms, with the spawned child's stdout coming back empty (build 92426, resolve.test.ts, six in a row).

#34069 describes the same state outside our CI, on macOS (kqueue): a bun test --parallel (or plain --isolate) worker pegged at 100% CPU inside spawnMaybeSync, the child a zombie, the pipes already closed, tickWithTimeout returning immediately, and the same nested-spawnSync escalation through the bun:test timeout path once the per-test timeout fires inside the spin. The accounting below is shared by the epoll and kqueue backends, and the new tests run on both.

Reproduced locally by running CI-shaped batches (bun test --parallel=3 --timeout=90000, CI's BUN_GARBAGE_COLLECTOR_LEVEL=1 environment, pinned to 4 CPUs): 3 of ~73 batches stalled or timed out the same way, and the stalled worker's main thread was busy-spinning inside BunObject_callback_spawnSync with its child already a zombie.

Cause

spawn_maybe_sync points vm.event_loop_handle at spawnSync's private uws loop for the duration of the call, so that the child's pidfd and pipe polls register on that loop. Everything that maintains a loop's keep-alive bookkeeping resolved that handle at the moment it ran, so it acted on whichever loop happened to be current:

• FilePoll::activate/deactivate (num_polls and active, plus the epoll/kqueue fd used to register and unregister),
• KeepAlive::ref_/unref (Loop::ref_/unref), used by servers, sockets, fetch, node:fs, dns, zlib, napi async work, ...
• timer::All::increment_timer_ref / increment_immediate_ref, which ref the loop when the first JS timer or immediate appears and unref it when the last one goes away,
• jsc::EventLoop::apply_concurrent_ref_delta, which folds the refKeepAlive counter used by MessagePort, BroadcastChannel and ScriptExecutionContext into vm.platform_loop_opt(), immediately on every JS-thread ref/unref.

So a ref taken on the main loop and released while a spawnSync is waiting was subtracted from the private loop instead. That happens whenever teardown runs during the wait: JSC sweeping a dead Timeout, port or pipe reader while spawnSync allocates its result (very frequent under --isolate + BUN_GARBAGE_COLLECTOR_LEVEL=1, where the previous file's leftovers are swept during the next file), or the test runner carrying on with the following tests after a test times out inside spawnSync. The private loop is reused for every spawnSync in the process, so the error persists for the rest of the worker's life.

us_loop_run_bun_tick returns immediately when loop->num_polls == 0. With the private loop's count off by one, a pipeless spawnSync (the napi harness) starts at 0 and spins from the first tick; a piped one reaches 0 as soon as its pipes hit EOF, before the pidfd event is dispatched. Either way the wait loop spins without polling and never observes the exit. The per-test timeout still fires inside the spin: it prints killed 1 dangling process into the worker's captured output, and if nothing is left to close the spin continues forever (the silent 240s variant); if pipe readers are still open, closing them makes the count non-zero, the loop polls once, and spawnSync returns the long-exited child with empty stdout (the timed-out variant), leaving the count wrong for the next call, hence the consecutive failures. The main loop is left with counts that are too high, which in a plain script also keeps the process from exiting.

A second problem in the same code: SpawnSyncEventLoop kept the saved handle in the struct that both levels of a nested spawnSync share (the timeout path above nests), so after the inner call returned, the outer call restored the private loop's handle and the VM stayed on the private loop for good.

Fix

Each counter records the loop it counted on and uncounts that one:

• FilePoll gets a counted_loop, used for unregister/deactivate, re-registration and the active-count adjustments (this also makes the unregister hit the epoll/kqueue instance the fd is actually registered with). Because the poll keeps the pointer, FilePoll::register/unregister and friends now take *mut Loop instead of &mut Loop and the callers pass the loop handle they already hold; the &'static mut accessor EventLoopCtx::platform_event_loop goes away with that.
• KeepAlive records the loop it ref'd. unref_on_next_tick keeps deferring through the pending counter when that is the thread's loop and unrefs directly otherwise, since only the thread's loop drains that counter.
• timer::All records the loop for each of its two counts.
• Every jsc::EventLoop records the uws loop it drives (uws_loop, previously a Windows-only field; the VM's loops get the thread's loop in ensure_waker, a spawnSync loop gets the private one) and folds its keep-alive counter into that.
• The handle returned by SpawnSyncEventLoop::prepare lives on the calling frame and is passed back to cleanup, so nesting restores correctly.

Why this is the right shape: the invariant that broke is "an increment and its matching decrement hit the same loop", and the handle swap itself is what spawnSync's own polls rely on to find the private loop, so the swap stays and each counter remembers its loop instead. That is independent of when or why the release happens (GC, the runner, user code), and the recorded pointers are always live when used: the thread's loop is freed by VirtualMachine::teardown only after timers are cancelled and the heap is destroyed (which is also when the last fold happens), and the private loop, owned by RareData, is freed after that. On Windows the first three counters go through the thread's loop regardless of the handle, so their new fields are cfg(not(windows)); the EventLoop counter did follow the swapped handle there too and is fixed on every platform.

Tests

test/js/bun/spawn/spawnsync-isolated-event-loop.test.ts gets a block of five cases. Each runs a small file under bun test in which test a enters a spawnSync after leaving its synchronous section and times out, so the runner executes the following tests while the private loop is current. a's spawnSync holds exactly one poll on the private loop, so one misdirected release is enough to make it spin forever; on the fixed build the release comes off the main loop, a's (killed) child is observed, and the file finishes with everything but a passing.

• four cases release one ref each of a different kind inside the wait: a JS timer (clearTimeout), a KeepAlive (Bun.serve().unref()), a registered FilePoll (cancelling a subprocess's stdout), and an event-loop keep-alive ref (BroadcastChannel.unref());
• the fifth nests a spawnSync inside the wait and then checks that the main loop is polled again afterwards (a child whose pidfd is registered on the main loop has its exit observed).

On the unfixed build all five fail (the inner bun test spins, the outer test times out and bun test kills it). On a build with the counter fixes but without the nested-handle fix, the four release cases pass and only the nesting case fails, so the cases are independent. Each case takes ~1.4s on a debug build; the block is deliberately sequential because bun test only kills a timed-out test's dangling processes when the test is not in a concurrent group, and that is what cleans up a spinning inner process on a regressed build.

Also ran the spawn, spawnSync, maxBuffer, pidfd, child_process, BroadcastChannel, MessagePort/worker, dns, macro, fs.watch, timers and setImmediate suites on the debug build, plus bun test --parallel=3 over the CI victim files with BUN_GARBAGE_COLLECTOR_LEVEL=1. The failures left in those runs are unrelated to this change: network-dependent dns lookups, RSS and throughput tests over their budget under ASAN, a pre-existing LSan report in worker-terminate-lifetime that reproduces with a plain require("fs"), and container-specific process/uid cases; the ones that were checked against an unfixed debug build fail identically there.

Fixes #34069