[robobun]

Fixes #28175
Closes BUN-2Q1E

Crash

Windows only. 1646 Sentry events with the same two frames, across bun 1.2.19 through 1.3.14, including compiled standalone executables:

uv__system_resume_callback   src/win/detect-wakeup.c
uv__wake_all_loops           src/win/core.c   <- SEGV reading a heap address

uv__wake_all_loops() is libuv's power-broadcast handler. When Windows resumes from sleep it walks libuv's global uv__loops[] registry and dereferences loop->iocp on every entry, so the crash means an entry points at a freed uv_loop_t. A loop is only removed from that registry when uv_loop_close() succeeds.

Cause

us_loop_free() in packages/bun-usockets/src/eventing/libuv.c tore down a non-default loop with:

uv_run(loop->uv_loop, UV_RUN_NOWAIT);
uv_loop_delete(loop->uv_loop);

uv_loop_delete() is the deprecated libuv helper:

err = uv_loop_close(loop);
assert(err == 0);      /* compiled out in release builds */
uv__free(loop);        /* unconditional */

If uv_loop_close() returns UV_EBUSY (any active request, or any non-internal handle still in handle_queue), the loop is freed anyway and stays registered in uv__loops[]. The next suspend/resume broadcast walks that entry and crashes, which is why the reports look like "crashed after being idle overnight".

The one place bun reaches this code is the per-VM spawnSync event loop: the first Bun.spawnSync() in a VM lazily creates a private uv_loop_t (SpawnSyncEventLoop), which RareData's drop frees through us_loop_free() when the VM is destroyed. For a node:worker_threads Worker that happens mid-process, so the dangling registry entry survives until the next resume. PR #24811 (shipped in bun 1.3.10) fixed the other registered loop, the worker's thread-local one, and this crash continued at the same rate through 1.3.14.

What leaves a handle on the loop at us_loop_free() time

Two things can:

1. A handle that was already uv_close()d but whose endgame is still gated on an in-flight IOCP completion (a cancelled overlapped read, a pending write completion, the process exit-wait packet). libuv only retires a closing handle from inside uv_run, and the spawn-sync loop is never run between the last explicit close and us_loop_free(), so every teardown relied on that single UV_RUN_NOWAIT turn racing those kernel completions. This is the reachable class, and a zero-timeout poll is structurally unable to handle it: it cannot wait for a completion that has not arrived.
2. A handle that nothing ever closes. I instrumented the unfixed debug build (uv_print_all_handles() at the top of us_loop_free()) and ran 19 distinct Bun.spawnSync shapes across about 70 Worker teardowns: extra-fd pipes, ipc, stdin: "pipe", timeouts, multi-megabyte unread stdin, grandchildren holding pipe ends open, terminating the Worker mid-spawnSync. Every handle on the loop at teardown was already closing (bun's finalizeStreams() explicitly uv_close()s them all first), so I could not find an instance of this class. The fix still defends against it so a future leak cannot re-introduce the crash.

Fix

us_loop_free() now drains the loop to completion instead of giving up:

• uv_walk() issues uv_close() for every handle still registered (class 2). Nothing touches them after us_loop_free();
• uv_run(UV_RUN_DEFAULT) runs until the loop reports dead. It waits for the in-flight IOCP completions that gate the remaining endgames (class 1), and with every handle closed the loop always drains to empty;
• uv_loop_close() then cannot return UV_EBUSY, and the storage is freed unconditionally. A debug assertion (live under bun bd) catches a future regression.

This is the same walk-then-drain-then-close sequence the worker's thread-local loop shutdown (Loop::shutdown(), the #24811 fix) already uses; us_loop_free() now matches it. Loop::shutdown()'s own drain is made unbounded for the same reason: uv_run(UV_RUN_DEFAULT) returns nonzero only when uv_stop cut it short.

uv_loop_new() is also replaced with malloc() + uv_loop_init() so the allocation and the free use the same allocator. uv_loop_new() goes through libuv's replaceable allocator, which bun points at mimalloc at startup, so a plain free() of its result would be an allocator mismatch.

Verification

The faulting read only happens on a real PBT_APMRESUMEAUTOMATIC power broadcast, which CI cannot generate, so there is no end-to-end reproduction. #24811 hit the same wall. The added test in test/js/bun/spawn/spawn-many-teardown.test.ts churns Workers through the stdio shapes that leave the most handles on the spawn-sync loop at teardown; under the debug build a drain that leaves the loop still registered aborts the child, so it is a regression canary for the teardown path rather than a reproduction of the IOCP race.

Verified on Windows x64 (debug build):

• bun bd test test/js/bun/spawn/spawn-many-teardown.test.ts passes (both tests), with no change in teardown time versus the old single-turn drain (the happy path still drains in one pass).
• A 13-scenario Worker + Bun.spawnSync churn probe (39 teardowns, the shapes listed above) runs clean against the new code.

Instrumented teardown from the probe against the unfixed build

The spawn-sync loop is alive going into the drain on every single teardown (the four usockets handles were just uv_close()d, and here an extra-fd uv_pipe_t is also still closing), so the entire safety of the old code rested on one UV_RUN_NOWAIT turn retiring everything before uv_loop_delete():

[PROBE us_loop_free] BEFORE alive=1
[-AI] async    000001BA860A08F8   (libuv internal wq_async)
[R--] prepare  000001BAD2D29E00
[R--] check    000001BAD2D2A040
[R--] timer    000001BB23B60050
[R--] async    000001BB1F68E250
[R--] pipe     000001BA86080280   (the extra-fd uv_pipe_t)
[PROBE us_loop_free] AFTER 1x NOWAIT alive=0
[-AI] async    000001BA860A08F8

[robobun]

^{Updated 10:57 PM PT - Jun 28th, 2026}

❌ @robobun, your commit fc2ac25 has 1 failures in Build #66607 (All Failures):

• test/cli/update_interactive_install.test.ts - code 1 on 🪟 2019 x64-baseline

---

🧪   To try this PR locally:

bunx bun-pr 33015

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

bun-33015 --bun

[coderabbitai]

Walkthrough

Updates libuv loop allocation and teardown in C and Rust to drain remaining handles before closing, and adds a Windows regression test for spawn teardown.

Changes

libuv Loop Teardown Drain

Layer / File(s)	Summary
C: loop allocation and teardown packages/bun-usockets/src/eventing/libuv.c	Adds create_uv_loop() to allocate and initialize non-default loops, routes us_create_loop() through it, adds a uv_walk close callback, and rewrites non-default loop teardown to drain handles before uv_loop_close() and freeing memory.
Rust: UV_EBUSY drain loop src/libuv_sys/libuv.rs	In Loop::shutdown, the UV_EBUSY branch now closes open handles with uv_walk, repeatedly calls uv_run(Default) until the loop drains, then closes the loop and clears the TLS slot.
Windows regression test for spawn teardown test/js/bun/spawn/spawn-many-teardown.test.ts	Adds a Windows-only regression test that writes worker and main fixtures, runs spawnSync teardown cases in workers, and asserts OK output with exit code 0.

Suggested reviewers

• Jarred-Sumner

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly describes the Windows segfault fix around libuv resume handling.
Description check	✅ Passed	The description covers the problem, cause, fix, and verification, but it does not follow the repository's requested section headings.
Linked Issues check	✅ Passed	The changes address the Windows sleep/wake segfault by draining and closing libuv loops before free, matching issue #28175.
Out of Scope Changes check	✅ Passed	The Rust shutdown adjustment and Windows regression test are directly related to the loop-teardown crash fix.

---

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

[coderabbitai]

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/libuv_sys/libuv.rs`:
- Around line 448-457: The retry close in the loop shutdown path is only checked
with a debug assertion, so a failed uv_loop_close can still be ignored in
release builds. In the shutdown logic around uv_run and uv_loop_close in
libuv.rs, replace the debug-only check with a real assert so the failure is
enforced before slot.set(ptr::null_mut()) clears the TLS entry. Keep the fix
scoped to the existing loop close sequence and the rc/ReturnCode::ZERO check.

In `@test/js/bun/spawn/spawn-many-teardown.test.ts`:
- Around line 65-77: Trim the comment in the spawn-many-teardown test so it only
keeps the issue URL and the durable invariant about the teardown bug. Remove the
extra PR/history and debug-build teardown narrative, and leave a single concise
regression comment near the relevant spawnSync teardown setup in
spawn-many-teardown.test.ts.
- Around line 105-108: The awaited promise in the worker setup can hang if the
worker exits before emitting a message or error. Update the promise wiring
around the worker event listeners to also reject on the worker’s exit event, and
make sure listeners are removed once the message is received. Use the existing
worker setup in the spawn-many teardown test to locate the change and keep all
failure paths covered.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 40456273-181a-466f-8d87-4133a824152d

📥 Commits

Reviewing files that changed from the base of the PR and between a1c39de and 9c08ad8.

📒 Files selected for processing (3)

• packages/bun-usockets/src/eventing/libuv.c
• src/libuv_sys/libuv.rs
• test/js/bun/spawn/spawn-many-teardown.test.ts

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

test/js/bun/spawn/spawn-many-teardown.test.ts (1)

131-132: 🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

Drop the explicit per-test timeout.

The 120_000 override on Line 132 fights the runner’s existing per-file timeout and can make this regression flake on slow debug/ASAN lanes by shrinking the effective budget. This spawn test does not match the documented timeout exceptions. As per coding guidelines, test/**/*.test.ts should not add explicit timeouts except documented special cases.

Suggested fix

 test.skipIf(!isWindows)(
   "the per-worker spawnSync libuv loop is fully drained and closed at worker teardown",
   async () => {
     using dir = tempDir("spawnsync-uvloop-teardown", {
       "worker.mjs": /* js */ `
         import { parentPort } from "node:worker_threads";
         const exe = process.execPath;
         // An extra "pipe" stdio entry lands a uv_pipe_t on the spawn-sync loop
         // that nothing reads; finalizeStreams only uv_close()s it, so its close
         // callback is still pending when the worker tears down.
         Bun.spawnSync({ cmd: [exe, "-e", "1"], stdio: ["ignore", "pipe", "pipe", "pipe"] });
         // A stdin write the child never drains plus a timeout, so the timeout
         // timer (whose callback calls uv_stop on the loop) and the writer are
         // both live late into the teardown.
         Bun.spawnSync({
           cmd: [exe, "-e", "Bun.sleepSync(60_000)"],
           timeout: 25,
           stdin: Buffer.alloc(1 << 20, 66),
           stdout: "pipe",
           stderr: "pipe",
         });
         parentPort.postMessage("done");
       `,
       "main.mjs": /* js */ `
         import { Worker } from "node:worker_threads";
         for (let i = 0; i < 6; i++) {
           const worker = new Worker(new URL("./worker.mjs", import.meta.url));
           await new Promise((resolve, reject) => {
             worker.on("message", resolve);
             worker.on("error", reject);
           });
           await worker.terminate();
         }
         console.log("OK");
       `,
     });

     await using proc = Bun.spawn({
       cmd: [bunExe(), "main.mjs"],
       env: bunEnv,
       cwd: String(dir),
       stdin: "ignore",
       stdout: "pipe",
       stderr: "pipe",
     });

     const [stdout, stderr, exitCode] = await Promise.all([proc.stdout.text(), proc.stderr.text(), proc.exited]);

     if (exitCode !== 0) {
       console.error(stderr);
     }
     expect(stdout.trim()).toBe("OK");
     expect(exitCode).toBe(0);
-  },
-  120_000,
+  },
 );

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@test/js/bun/spawn/spawn-many-teardown.test.ts` around lines 131 - 132, Remove
the explicit 120_000 timeout from the spawn-many teardown test so it uses the
existing suite/file timeout instead. Update the test declaration in
spawn-many-teardown.test.ts (the test wrapper around the spawn-many teardown
scenario) to omit the extra per-test override, since this case is not a
documented timeout exception and should rely on the runner’s default budget.

Sources: Coding guidelines, Learnings

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@test/js/bun/spawn/spawn-many-teardown.test.ts`:
- Around line 131-132: Remove the explicit 120_000 timeout from the spawn-many
teardown test so it uses the existing suite/file timeout instead. Update the
test declaration in spawn-many-teardown.test.ts (the test wrapper around the
spawn-many teardown scenario) to omit the extra per-test override, since this
case is not a documented timeout exception and should rely on the runner’s
default budget.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 70d17da1-031d-483b-adfd-98642a87d872

📥 Commits

Reviewing files that changed from the base of the PR and between 9c08ad8 and 302c217.

📒 Files selected for processing (1)

• test/js/bun/spawn/spawn-many-teardown.test.ts

[robobun]

Addressed the two test findings in f33731a: the fixture now rejects on an early worker exit (via Promise.withResolvers), and the header comment is trimmed to the issue URL plus the invariant.

Two I'm declining, with reasons:

• Loop::shutdown's debug_assert_eq! (inline thread): with the added drain, the retry close cannot fail on a reachable path, and a release assert_eq! would turn any future stuck-handle bug into a hard process abort at worker teardown, which is a worse failure mode than the one this PR removes.
• The 120_000 test timeout (out-of-diff note): the sibling test in this file and most of test/js/bun/spawn/ set the same value, and on the lanes this test runs on the runner's per-test default is 90_000 (scripts/runner.node.mjs), so the explicit 120_000 raises the budget rather than shrinking it. The test starts a dozen debug bun child processes, so the extra headroom is deliberate.

[claude]

My earlier nits are addressed in f33731a — thanks. Deferring to a human on the merge: this rewrites event-loop teardown in both usockets (us_loop_free) and the Rust Loop::shutdown path, and the last CI run reported build-rust failures across the non-Windows targets that are worth confirming as resolved/unrelated before landing.

Extended reasoning...

Overview

This PR changes three files to fix a Windows-only SEGV (1646 Sentry events) where a freed uv_loop_t remains in libuv's global uv__loops[] registry and is dereferenced by uv__wake_all_loops() on power-resume:

• packages/bun-usockets/src/eventing/libuv.c: replaces uv_loop_new()/uv_loop_delete() with explicit malloc+uv_loop_init() and a bounded uv_run(NOWAIT) drain followed by uv_loop_close(), freeing the storage only on success (leaking on UV_EBUSY).
• src/libuv_sys/libuv.rs: in Loop::shutdown()'s UV_EBUSY recovery branch, replaces a single uv_run(DEFAULT) with a bounded 16-spin loop so stop_flag and IOCP-gated endgames don't defeat the retry close.
• test/js/bun/spawn/spawn-many-teardown.test.ts: adds a Windows-only canary test that churns Workers through spawnSync shapes that leave handles on the spawn-sync loop at teardown.

Security risks

None identified. No user-controlled input reaches the changed code; this is internal lifecycle/teardown logic. The worst-case new behavior is a deliberate small leak of a uv_loop_t struct rather than a UAF.

Level of scrutiny

High. us_loop_free() and Loop::shutdown() are core event-loop lifecycle paths that run on every Worker/VM teardown. The reasoning is well-argued (and the uv_loop_delete → conditional-free change is clearly correct in isolation), but the bounded-drain semantics, allocator pairing (malloc/free vs libuv's replaceable allocator), and the choice to leak-on-EBUSY are design decisions a maintainer should sign off on. The author explicitly notes the test is a canary, not a reproduction of the race.

Other factors

• The robobun CI comment reports build-rust failures on 11 non-Windows targets for commit 302c217; the only commit since (f33731a) touched only the test file, so the Rust build status should be confirmed before merge.
• All three CodeRabbit findings and both of my earlier inline nits (comment length, wiring worker.on('exit')) were addressed or reasonably declined; nothing outstanding from automated review.
• No bugs found by the bug-hunting system.

[robobun]

CI status, final, for whoever reviews this.

The diff is green everywhere it runs. Every build lane on every target, cargo clippy, and every Windows test lane pass. Windows is the only platform that compiles the changed code (packages/bun-usockets/src/eventing/libuv.c is behind #ifdef LIBUS_USE_LIBUV, src/libuv_sys/libuv.rs is #![cfg(windows)]), and the new test is test.skipIf(!isWindows).

Build 66607 (the current head) has finalized with exactly two red jobs, both unrelated to this diff:

1. darwin-26-aarch64-test-bun failed before running a single test, on two consecutive builds of this branch (66530 and 66607), on the same agent (darwin-aarch64-26-5-1-1):

   Error: buildkite-agent artifact download timed out after 120s for step 'darwin-aarch64-build-bun'. Refusing to continue with a partial download (would silently fall back to the wrong binary).
   

   That is the test runner refusing to start because the Buildkite artifact store could not serve the macOS build within its 120 second budget, and it is not auto-retried. Retrying that one job in Buildkite clears it.

2. windows-2019-x64-baseline-test-bun: test/cli/update_interactive_install.test.ts failed in its own setup, where the bun install it spawns to prepare its fixture exited 1 instead of 0 (expect(installExitCode).toBe(0) at line 29). That is a bun update --interactive CLI test with no overlap with the libuv loop teardown this PR changes, and the same file passed on both previous builds of this identical tree (66468 and 66530).

The previous build of this branch (66468) went fully green end to end, so the pipeline is proven to pass on this tree. I already pushed one empty-commit re-run (66607 is that re-run) and it reproduced the same artifact timeout, so I will not push another; the two job retries are one click each in Buildkite.

The bun-plugin-svelte GitHub Action is also red. It tests packages/bun-plugin-svelte against BUN_VERSION: "canary", not this branch's build, and only runs here because the usockets file matches the workflow's packages/** path filter; nothing in this PR can influence it.

[Jarred-Sumner]

Fix the underlying issue leading it to not free the loop

[robobun]

Done in 74c5d0c. us_loop_free() now issues uv_close() (via uv_walk()) for every handle still registered and runs uv_run(UV_RUN_DEFAULT) until the loop reports dead, so uv_loop_close() always succeeds and the uv_loop_t is always freed. No leak-on-UV_EBUSY path left. This is the same walk-then-drain sequence Loop::shutdown() (#24811) already uses for the worker's thread-local loop.

On what leaves the loop busy, there are two classes and both are now handled structurally:

1. A handle that was already uv_close()d but whose endgame is still gated on an IOCP completion that has not arrived yet (a cancelled overlapped read, a pending write completion, the process exit-wait packet). libuv only retires closing handles from inside uv_run, and the spawn-sync loop is never run again between the last explicit close and us_loop_free(), so every teardown raced those kernel completions against a single zero-timeout UV_RUN_NOWAIT poll. This is the reachable class and the real underlying issue; UV_RUN_DEFAULT waits for those completions instead of racing them.
2. A handle bun never closed. I instrumented the unfixed debug build (uv_print_all_handles() at the top of us_loop_free()) across 19 Bun.spawnSync shapes and about 70 Worker teardowns and every handle on the loop was already closing (finalizeStreams() explicitly closes them all first), so I could not find one. The uv_walk() closes anything that class would leave behind so a future leak cannot re-introduce the crash either.

Verified on Windows x64: both tests in spawn-many-teardown.test.ts pass, and a 13-scenario Worker + spawnSync churn probe (39 teardowns) runs clean, with no change in teardown time (the happy-path drain is still a single pass). I updated the PR title and description to match.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/libuv_sys/libuv.rs`:
- Around line 445-448: The comment block in the libuv loop handling section is
too long and should be condensed to fit the 3-line limit while preserving the
SAFETY note. Update the contiguous comment near the `uv_run(Default)` logic in
`libuv.rs` to remove or merge the explanatory lines so it stays within three
lines, and keep the `SAFETY: loop_ is the live per-thread loop` statement
intact.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: f56aabad-938a-4350-b5a8-cb2851042b68

📥 Commits

Reviewing files that changed from the base of the PR and between 302c217 and fc2ac25.

📒 Files selected for processing (3)

• packages/bun-usockets/src/eventing/libuv.c
• src/libuv_sys/libuv.rs
• test/js/bun/spawn/spawn-many-teardown.test.ts

[claude]

Both earlier nits are addressed and I didn't find anything new, but the unbounded uv_walk + while (uv_run(UV_RUN_DEFAULT)) drain in us_loop_free() and the allocator swap for uv_loop_t are the kind of native event-loop lifecycle change that's worth a human sign-off.

Extended reasoning...

Overview

This PR fixes a Windows-only segfault (1646 Sentry events) where uv__wake_all_loops() dereferences a freed uv_loop_t after system resume. It touches three files: packages/bun-usockets/src/eventing/libuv.c rewrites us_loop_free() to uv_walk + drain via while (uv_run(UV_RUN_DEFAULT)) + uv_loop_close() + free() (replacing one UV_RUN_NOWAIT turn + the deprecated uv_loop_delete()), and adds a create_uv_loop() helper that pairs malloc/free instead of going through libuv's mimalloc-backed allocator. src/libuv_sys/libuv.rs makes the analogous change in Loop::shutdown's UV_EBUSY recovery, looping uv_run(Default) until it returns 0. A new Windows-only regression test churns Workers through Bun.spawnSync shapes that leave handles on the spawn-sync loop at teardown.

Security risks

None identified. No untrusted input, auth, crypto, or permissions surface; this is internal event-loop lifecycle management reached only at VM/Worker teardown.

Level of scrutiny

High. This is native C/Rust code on a critical path (libuv loop lifecycle, Worker teardown) with subtle invariants: the new drain is unbounded and relies on "every handle is closed → UV_RUN_DEFAULT must terminate" holding for every shape that can land on the spawn-sync loop, and the allocator-pairing change must be correct across the one call site. The PR description is exceptionally thorough (instrumented 19 spawnSync shapes / ~70 teardowns, matches the #24811 pattern), and the reasoning for termination is sound, but a maintainer familiar with the usockets/libuv integration should confirm the unbounded drain can't wedge a Worker teardown in some shape not covered by the probe.

Other factors

The bug-hunting system found nothing. Both of my prior inline nits (trim the regression comment, wire worker.on('exit')) and all CodeRabbit findings are resolved or reasonably declined (the debug_assert_eq! decision is well-argued). No CODEOWNERS entry covers these paths. CI: Windows test lanes are green; the remaining red checks are explained by the author as a canary-bun bun-plugin-svelte snapshot unrelated to this diff and a Buildkite artifact-download timeout, with an empty retrigger commit pushed. Given the change is well-reasoned but touches a hang-or-crash-if-wrong native teardown path, I'm deferring rather than approving.

[robobun]

On the one open question (can the unbounded drain wedge a Worker teardown?), here is the termination argument in one place.

1. uv_walk() runs first and issues uv_close() for every handle on the loop that is not already closing, so after the walk every handle is in the CLOSING state and nothing can start a new operation.
2. A closing handle's endgame is gated on at most one of: a pending read (which uv_close cancels via CancelIoEx, whose completion the kernel always delivers), the process exit-wait packet (which the already-registered wait callback always posts), or nothing at all (the common case, where the endgame is queued immediately and retires on the first pass).
3. The one thing libuv does not cancel on uv_close is a pending write request. A write on the spawn-sync loop can only be to the child's stdin, and the sync driver waits for the child to exit before returning, at which point the child's read end is gone and the kernel completes every outstanding write with an error. I also probed the adversarial shape explicitly (a child that hands its stdin read end to a detached grandchild and then exits, with a multi-megabyte stdin) and the teardown still completes immediately.
4. uv_run(UV_RUN_DEFAULT) only returns nonzero when uv_stop() cut it short. The only uv_stop() on the spawn-sync loop is the spawnSync timeout timer's callback, which can only fire from inside a uv_run on that same loop, and SpawnSyncEventLoop::Drop has already uv_timer_stop()d and uv_close()d that timer before us_loop_free() runs. So the while body is a defensive re-entry, not something that loops.

This is the same uv_walk followed by run-to-dead sequence that the worker's thread-local loop shutdown (Loop::shutdown(), #24811) has used since bun 1.3.10, on a loop that carries far more handle variety (timers, tty, fs, pipes, sockets), so the idiom has real mileage. And on every path the instrumented probe exercised, the loop was already dead after a single pass, so the happy-path teardown time is unchanged.

[robobun]

Stale PR review: keep open, rework.

The defect is still on main. us_loop_free frees an owned loop with one uv_run(UV_RUN_NOWAIT) turn and then uv_loop_delete() (packages/bun-usockets/src/eventing/libuv.c:363-366). uv_loop_delete() frees the uv_loop_t even when uv_loop_close() fails. The check is only an assert (oven-sh/libuv@8023581, src/uv-common.c:914-918). The uv__wake_all_loops crash is still reported on 1.3.14.

The current diff is not the shape to merge:

• It answers the open review ("Fix the underlying issue leading it to not free the loop") with an unbounded while (uv_run(uv_loop, UV_RUN_DEFAULT)) drain. Worker / worker_threads: WebCore-shaped lifetimes, joined threads, one ordered VM teardown #37075 removed that idiom from the worker loop teardown. Loop::close_thread_loop now turns the loop at most 64 times with RunMode::NoWait. Its comment says RunMode::Default can wait on idle state and never return (src/libuv_sys/libuv.rs:484-488).
• In a release build the new code still calls free(uv_loop) when uv_loop_close() fails. The check is compiled only under ASSERT_ENABLED.
• No run in the PR shows uv_loop_close() failing at this site. The probe in the body shows the loop dead after one UV_RUN_NOWAIT turn (AFTER 1x NOWAIT alive=0). The cause that the review asks for is still a theory.
• Both source files conflict with main. The src/libuv_sys/libuv.rs hunk patches Loop::shutdown, which Worker / worker_threads: WebCore-shaped lifetimes, joined threads, one ordered VM teardown #37075 replaced with close_thread_loop.
• The only decoded stack trace in Segfault after ~24h idle on Windows 11 with sleep/wake cycles #28175 (comment of 2026-04-10) is _mi_memcpy on the HTTP thread. No trace in that issue shows uv__wake_all_loops, so the Fixes #28175 line would close that issue without evidence.

The wanted shape is #42819 (Remove libuv on Windows). It deletes libuv.c and src/libuv_sys. Its us_loop_free (packages/bun-usockets/src/eventing/iocp.c) removes the loop from Bun's own resume list under a lock, then frees it. A resume callback cannot reach a freed loop.

If an interim fix is needed before #42819 lands, open a new PR on current main that changes only us_loop_free. Use a bounded number of UV_RUN_NOWAIT turns and a direct uv_loop_close() call. When the close fails, leak the uv_loop_t. #41412 uses that policy for the worker loop. Close this PR when #42819 lands.