usockets: make us_create_loop fallible instead of aborting on EMFILE

[robobun]

Repro

// sh -c 'ulimit -n 512; exec bun repro.ts'
import * as fs from "node:fs";
const held = [];
for (;;) { try { held.push(fs.openSync("/dev/null", "r")); } catch { break; } }
await fetch("http://127.0.0.1:1/").catch(e => console.error("rejected:", e.code));
for (const fd of held) fs.closeSync(fd);
console.error("SURVIVED");

Before (both fetch and new Worker() at the fd limit):

panic: eventfd() failed during loop init (out of file descriptors?)

SIGABRT, exit 134. Node at the same limit rejects that one fetch (TypeError: fetch failed) / fires ERR_WORKER_INIT_FAILED on that one Worker, then recovers.

Cause

On Linux, us_create_loop acquires three fds: epoll_create1, timerfd_create for the sweep timer, and eventfd for the wakeup async. The eventfd failure was a deliberate BUN_PANIC; the other two were never checked. The first fetch() spawns the HTTP-client thread and the first new Worker() spawns a worker thread; both lazily create their own per-thread uSockets loop via uWS::Loop::get(), which reached the panic and took the whole process down.

Fix

us_create_loop now returns NULL when any of the init syscalls fail, cleaning up whatever was acquired. us_internal_loop_data_init returns int so the caller can unwind. uWS::Loop::get() returns nullptr and leaves the per-thread lazy slot empty so a later call retries.

Callers:

• VirtualMachine::init returns Err(EMFILE) before ensure_waker would dereference a null loop.
• WebWorker::thread_main turns start_vm() Err into an error event on the parent Worker (new WebWorker__dispatchErrorMessage shim that only needs the parent-side Worker*) plus the existing null-vm shutdown(), instead of Output::panic.
• HTTP client on_start checks uws::Loop::get() before init_global; while null it rejects every queued fetch with FailedToOpenSocket (via new AsyncHTTP::fail_before_start) and retries, so a later fetch succeeds once fds free up.

Also fixes the pre-existing leak of the poll allocation when timerfd_create or eventfd fails.

Related: #33848 handles the adjacent case where the loop itself comes up but the GC controller's us_create_timer fails (3-4 spare fds). This PR is the 0-spare-fd variant that #33848 explicitly scoped out.

Verification

test/js/bun/util/emfile-loop-init.test.ts (POSIX-only) runs both scenarios under ulimit -n 512: fills the fd table, issues the first fetch() / new Worker(), asserts the process exits 0 with SURVIVED and the per-operation error. Fails on main with exit 134 / panic: eventfd() failed during loop init; passes with this change.

---

[review] gate passed · iteration 4 · 11 files touched

fails on main (without fix)

ASAN without fix: 2 FAILED
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/mechgate.xml" test/js/bun/util/emfile-loop-init.test.ts
info: syncing channel updates for nightly-2026-05-06-x86_64-unknown-linux-gnu
info: latest update on 2026-05-06 for version 1.97.0-nightly (e95e73209 2026-05-05)
info: component rust-src is up to date
info: checking for self-update (current version: 1.29.0)
bun test v1.4.0 (f29437aca)

test/js/bun/util/emfile-loop-init.test.ts:
(fail) lazy event-loop creation under EMFILE > first fetch() rejects instead of aborting the process [5007.72ms]
  ^ this test timed out after 5000ms.
(fail) lazy event-loop creation under EMFILE > first new Worker() fires an error event instead of aborting the process [5006.11ms]
  ^ this test timed out after 5000ms.

 0 pass
 2 fail
Ran 2 tests across 1 file. [7.01s]
error: script "bd" exited with code 1
__F:2:S:0

release without fix: all passed
bun test v1.4.0-canary.1 (2b4acd612)

test/js/bun/util/emfile-loop-init.test.ts:
(pass) lazy event-loop creation under EMFILE > first new Worker() fires an error event instead of aborting the process [28.27ms]
(pass) lazy event-loop creation under EMFILE > first fetch() rejects instead of aborting the process [76.79ms]

 2 pass
 0 fail
 5 expect() calls
Ran 2 tests across 1 file. [227.00ms]
__F:0:S:0

passes on PR (with fix)

ASAN with fix: all passed
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/mechgate.xml" test/js/bun/util/emfile-loop-init.test.ts
info: syncing channel updates for nightly-2026-05-06-x86_64-unknown-linux-gnu
info: latest update on 2026-05-06 for version 1.97.0-nightly (e95e73209 2026-05-05)
info: component rust-src is up to date
info: checking for self-update (current version: 1.29.0)
bun test v1.4.0 (f29437aca)

test/js/bun/util/emfile-loop-init.test.ts:
(pass) lazy event-loop creation under EMFILE > first new Worker() fires an error event instead of aborting the process [1364.96ms]
(pass) lazy event-loop creation under EMFILE > first fetch() rejects instead of aborting the process [1415.06ms]

 2 pass
 0 fail
 5 expect() calls
Ran 2 tests across 1 file. [3.40s]
__F:0:S:0

release with fix: all passed
$ bun scripts/build.ts --profile=release
info: syncing channel updates for nightly-2026-05-06-x86_64-unknown-linux-gnu
info: latest update on 2026-05-06 for version 1.97.0-nightly (e95e73209 2026-05-05)
info: component rust-src is up to date
info: checking for self-update (current version: 1.29.0)
[configured] bun-profile → bun (stripped) in 686ms (unchanged)
ninja: Entering directory `/workspace/bun/build/release'
[1/26] cc obj/packages/bun-usockets/src/context.c.o
[2/26] cc obj/packages/bun-usockets/src/bsd.c.o
[3/26] cc obj/packages/bun-usockets/src/fault_inject.c.o
[4/26] cc obj/packages/bun-usockets/src/crypto/openssl.c.o
[5/26] cc obj/packages/bun-usockets/src/eventing/libuv.c.o
[6/26] cc obj/packages/bun-usockets/src/loop.c.o
[7/26] cc obj/packages/bun-usockets/src/socket.c.o
[8/26] cc obj/packages/bun-usockets/src/udp.c.o
[9/26] cc obj/packages/bun-usockets/src/eventing/epoll_kqueue.c.o
[10/26] cc obj/packages/bun-usockets/src/quic.c.o
[11/26] cxx obj/unified/UnifiedSource-src_uws_sys-0.cpp.o
[12/26] cxx obj/unified/UnifiedSource-packages_bun_usockets_src_crypto-0.cpp.o
[13/26] cxx obj/unified/UnifiedSource-src_jsc_bindings_node-0.cpp.o
[14/26] cxx obj/src
... (truncated)

diff hotspot

packages/bun-usockets/src/eventing/epoll_kqueue.c | 23 ++++--
 packages/bun-usockets/src/eventing/libuv.c        |  2 +-
 packages/bun-usockets/src/internal/internal.h     |  8 +--
 packages/bun-usockets/src/loop.c                  | 13 +++-
 packages/bun-uws/src/Loop.h                       | 15 +++-
 src/http/AsyncHTTP.rs                             | 25 +++++++
 src/http/HTTPThread.rs                            | 15 ++++
 src/jsc/VirtualMachine.rs                         |  6 ++
 src/jsc/bindings/webcore/Worker.cpp               |  5 ++
 src/jsc/web_worker.rs                             | 22 ++++--
 test/js/bun/util/emfile-loop-init.test.ts         | 86 +++++++++++++++++++++++
 11 files changed, 201 insertions(+), 19 deletions(-)

gate history · 7 passed · 0 rejected · iteration 4

evidence per changed file

file                                               reads  edits  tests
packages/bun-usockets/src/eventing/epoll_kqueue.c      5      5      0
packages/bun-usockets/src/eventing/libuv.c             2      1      0
packages/bun-usockets/src/internal/internal.h          1      1      0
packages/bun-usockets/src/loop.c                       3      3      0
packages/bun-uws/src/Loop.h                            1      2      0
src/http/AsyncHTTP.rs                                  8      5      0
src/http/HTTPThread.rs                                 7      3      0
src/jsc/VirtualMachine.rs                              6      5      0
src/jsc/bindings/webcore/Worker.cpp                    2      2      0
src/jsc/web_worker.rs                                  6      8      0
test/js/bun/util/emfile-loop-init.test.ts              2      9      0

[coderabbitai]

Walkthrough

This PR makes event-loop creation and async allocation resilient to file-descriptor exhaustion. Bun’s HTTP thread, VM initialization, and Worker startup now propagate failures without aborting, with regression coverage for fetch and Worker scenarios.

Changes

EMFILE-safe event loop creation and failure propagation

Layer / File(s)	Summary
uSockets loop and async creation failure handling packages/bun-usockets/src/eventing/epoll_kqueue.c, packages/bun-usockets/src/eventing/libuv.c, packages/bun-usockets/src/internal/internal.h, packages/bun-usockets/src/loop.c	Backend loop creation, internal loop-data initialization, and EPOLL eventfd allocation now check failures, clean up allocated resources, and return failure values instead of continuing or panicking.
uWS Loop::create and Loop::get null checks packages/bun-uws/src/Loop.h	Loop::create checks us_create_loop before initialization, and Loop::get leaves the lazy loop unset when creation fails.
HTTP thread retry loop and request failure on EMFILE src/http/AsyncHTTP.rs, src/http/HTTPThread.rs	AsyncHTTP::fail_before_start rejects queued requests through their result callback; HTTPThread::on_start drains queued tasks, reports FailedToOpenSocket, retries loop creation every 50ms, and initializes the event loop after success.
VirtualMachine init and Worker startup failure handling src/jsc/VirtualMachine.rs, src/jsc/web_worker.rs, src/jsc/bindings/webcore/Worker.cpp	VM initialization returns an EMFILE error when loop creation fails. Worker startup dispatches initialization errors through the new C ABI shim, records exit code 1, and uses it during shutdown instead of panicking.
EMFILE regression test test/js/bun/util/emfile-loop-init.test.ts	A POSIX-only suite exhausts file descriptors and verifies graceful fetch() and Worker failures, clean process survival, and normal retry behavior after descriptors are released.

Suggested reviewers: Jarred-Sumner

🚥 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 accurately states the main change: making us_create_loop fallible instead of aborting on EMFILE.
Description check	✅ Passed	The description covers the problem, root cause, fix, and verification, though it uses custom headings instead of the template.

---

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

[robobun]

^{Updated 8:15 PM PT - Jul 11th, 2026}

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

• test/js/third_party/grpc-js/test-tonic.test.ts - crash reported on 🍎 14 aarch64

---

🧪   To try this PR locally:

bunx bun-pr 33850

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

bun-33850 --bun

[coderabbitai]

Actionable comments posted: 3

Caution

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

⚠️ Outside diff range comments (1)

packages/bun-uws/src/Loop.h (1)

117-137: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Minor asymmetry between the two get() branches.

The existingNativeLoop branch doesn't explicitly check create(existingNativeLoop) for null, unlike the newly-added null check in the other branch — functionally harmless since getLazyLoop().loop just stays null either way, but worth aligning for readability/consistency.

🤖 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 `@packages/bun-uws/src/Loop.h` around lines 117 - 137, The get() method in Loop
currently handles the existingNativeLoop path differently from the nullptr path,
which makes the control flow asymmetric and harder to read. Update the get(void
*existingNativeLoop) logic so both branches follow the same null-check pattern
around create(...), using the Loop::get and create symbols to keep the handling
consistent while preserving the current behavior of leaving getLazyLoop().loop
null on failure.

🤖 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 `@test/js/bun/util/emfile-loop-init.test.ts`:
- Line 79: The current assertion in the EMFILE loop init test is too generic and
can pass for unrelated worker failures; update the check around the stderr
expectation in the test to assert the actual worker initialization failure
message emitted by thread_main, using the Worker initialization failed text (or
the full Worker initialization failed: {err.name()} form) instead of only worker
error:. This should be done in the emfile-loop-init test near the existing
stderr assertion so the test specifically verifies the EMFILE-handling path.
- Around line 14-17: Strengthen the emfile-loop-init test by asserting the exact
error codes produced by the two fetch attempts instead of matching generic
stderr substrings. Update the assertions around the fetch handling in
emfile-loop-init.test.ts so the first fetch explicitly expects e.code to be
"FailedToOpenSocket" and the retry asserts the normal connect-failure code
rather than another "FailedToOpenSocket"; use the existing fetch/retry logging
path and the FetchTasklet mapping as the guide.
- Around line 28-46: The Worker fixture cleanup is not guaranteed to run if the
Promise never settles or an earlier step throws, so move the fd closing loop and
fs.unlinkSync(W) into a try/finally around the Worker setup in workerFixture.
Keep the cleanup in the finally block so held descriptors are always closed and
the temp file is always removed, even on hang or error paths.

---

Outside diff comments:
In `@packages/bun-uws/src/Loop.h`:
- Around line 117-137: The get() method in Loop currently handles the
existingNativeLoop path differently from the nullptr path, which makes the
control flow asymmetric and harder to read. Update the get(void
*existingNativeLoop) logic so both branches follow the same null-check pattern
around create(...), using the Loop::get and create symbols to keep the handling
consistent while preserving the current behavior of leaving getLazyLoop().loop
null on failure.

🪄 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: 6ee92ddc-8856-4e0e-8ce0-882b2683d23f

📥 Commits

Reviewing files that changed from the base of the PR and between fc865b3 and 2e4456f.

📒 Files selected for processing (11)

• packages/bun-usockets/src/eventing/epoll_kqueue.c
• packages/bun-usockets/src/eventing/libuv.c
• packages/bun-usockets/src/internal/internal.h
• packages/bun-usockets/src/loop.c
• packages/bun-uws/src/Loop.h
• src/http/AsyncHTTP.rs
• src/http/HTTPThread.rs
• src/jsc/VirtualMachine.rs
• src/jsc/bindings/webcore/Worker.cpp
• src/jsc/web_worker.rs
• test/js/bun/util/emfile-loop-init.test.ts

[robobun]

CI on 751ddf9: the only failure is the Windows x64 build-cpp lane failing to download the libuv tarball (Failed to download after 5 attempts: https://github.com/oven-sh/libuv/archive/4dcfac...tar.gz), which is a network/infra issue unrelated to this diff.

The x64-asan lane (which caught the real leak on the first push) passes. All Linux and macOS lanes that completed are green, and all review threads are resolved. This is ready for a maintainer to re-run the Windows build lane or merge.

[robobun]

CI on f29437a (rebased onto 588da0e): the only hard failure is test/js/third_party/grpc-js/test-tonic.test.ts on darwin 14 aarch64, where the macOS agent's rustup has no default toolchain (rustup could not choose a version of cargo to run), so the tonic server never starts and the test harness OOMs waiting for it. test/napi/napi.test.ts on Windows 2019 x64 is flaky (passed on retry; same GC-timing flake as build 71052). Neither touches this diff; test/js/bun/util/emfile-loop-init.test.ts passes everywhere it ran.

All review threads resolved. Ready for a maintainer to re-run the darwin lane or merge.

[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 `@packages/bun-usockets/src/eventing/libuv.c`:
- Line 178: Handle the return value of us_internal_loop_data_init in
us_create_loop instead of discarding it; when it returns -1, mirror the
epoll/kqueue cleanup path by unwinding uv_pre and uv_check, deleting any owned
uv_loop, and returning NULL.

🪄 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: ee1d8ff0-7671-4d47-a250-babcd7c32342

📥 Commits

Reviewing files that changed from the base of the PR and between 2e4456f and 61b3f3e.

📒 Files selected for processing (11)

• packages/bun-usockets/src/eventing/epoll_kqueue.c
• packages/bun-usockets/src/eventing/libuv.c
• packages/bun-usockets/src/internal/internal.h
• packages/bun-usockets/src/loop.c
• packages/bun-uws/src/Loop.h
• src/http/AsyncHTTP.rs
• src/http/HTTPThread.rs
• src/jsc/VirtualMachine.rs
• src/jsc/bindings/webcore/Worker.cpp
• src/jsc/web_worker.rs
• test/js/bun/util/emfile-loop-init.test.ts

[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/http/AsyncHTTP.rs`:
- Around line 599-615: Condense the documentation and safety comments on
AsyncHTTP::fail_before_start to no more than three lines each, while preserving
the contract that http is a live JS-thread-owned value removed from
HttpThread::queued_tasks and that the callback receives the failure.

In `@src/http/HTTPThread.rs`:
- Around line 1274-1278: Condense the startup comment immediately before the
uSockets loop initialization to no more than three lines while preserving its
essential points: ensure the loop exists before init_global dereferences it,
handle loop-creation failure by rejecting queued fetches with
FailedToOpenSocket, and allow retry after file descriptors are available.

In `@src/jsc/VirtualMachine.rs`:
- Around line 1993-1996: Shorten the initialization comment near the uSockets
loop setup to no more than three lines, retaining only the essential invariant
that Loop::get() may return null and must be checked before allocations so the
null-VM shutdown path has nothing to reclaim.

🪄 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: 0ee20e3f-b922-499c-8c61-c2f1665ed2a7

📥 Commits

Reviewing files that changed from the base of the PR and between 61b3f3e and 2b4acd6.

📒 Files selected for processing (8)

• packages/bun-usockets/src/eventing/epoll_kqueue.c
• packages/bun-usockets/src/eventing/libuv.c
• packages/bun-usockets/src/internal/internal.h
• packages/bun-usockets/src/loop.c
• packages/bun-uws/src/Loop.h
• src/http/AsyncHTTP.rs
• src/http/HTTPThread.rs
• src/jsc/VirtualMachine.rs

[Jarred-Sumner]

This is a fake fix. Just abort.

[robobun]

Closing per the above. Happy to take a different approach if there's one you'd prefer (e.g. only the Worker path, or leaving the HTTP thread alone and just failing the first fetch without the retry loop); otherwise I'll leave the original abort in place.