Bun parity: remaining open items to reach 100% test-suite pass

[chrisbbreuer]

Tracking issue for the remaining work to reach 100% parity with Bun's official test suite (~/Code/bun, pinned SHA fd0b6f1a27), runnable here via home test. Each item has the root cause traced during investigation. We tackle them top-to-bottom; check off as landed (small fix:/feat: commits, pushed).

How to run / verify

• Build: HOME_BUN_OBJ_ROOT=/tmp/bun-pinned/build/release/obj HOME_BUN_WEBKIT_LIB=~/.bun/build-cache/webkit-5488984d20e0dbfe-arm64/lib ./pantry/.bin/zig build
• Test: cd /tmp/bun-pinned && home test test/js/... (run files sequentially with a pkill -9 -f zig-out/bin/home between them — parallel runs cause resource-exhaustion false hangs).
• Release build (-Doptimize=ReleaseSafe) clears debug-assert crashes and gives honest leak numbers.

---

A. node:tls socket layer

• getCipher() cluster works — was a false diagnosis: the null cipher/session came from the broken (cert-less) handshake caused by the Buffer-cert gap, now fixed (b3492d3). Verified locally: getCipher {TLS_AES_128_GCM_SHA256, version:"TLSv1/SSLv3"} (matches pin test), getProtocol TLSv1.3, getSession 1106-byte Buffer, getEphemeralKeyInfo/getSharedSigalgs/exportKeyingMaterial/isSessionReused all correct. The pin test connects to bun.sh (crashes on this macOS 27 box) so it can't be run here, but the behavior is confirmed.
• getPeerCertificate at pin parity — abbreviated works (17 keys, CN populated); earlier {} was a test error (called with false→ the non-abbreviated path). The detailed/issuerCertificate-chain path is a literal TODO at tls_socket_functions.zig:149 — identical in the pin, so pin tests needing it fail there too (not a Home gap).
• ALPN — fixed in 428aa2c (hand-mirror SSLConfig.fromJS never parsed ALPNProtocols).
• SNI server.addContext() — fixed in 4ed9a49. The hand-mirror read only serverName, not its servername altName (which node:tls passes), so the client sent no SNI → server context selection never matched. Isolated addContext test now passes (context1/context2 authorize via their CA, unknowncontext falls back). Remaining node-tls-context failures are the file's external-connecting tests (machine's TLS-network crash).
• Cert-chain verification — "unable to verify the first certificate" / "unable to get issuer certificate" on incomplete-chain + intermediate-CA scenarios (basic single-CA verify works).
• Config validation — tls.createServer({passphrase: wrong}) should reject but listens; passphrase IS passed to us_ssl_ctx_from_options, so it's uws-level validation timing/error-surfacing.
• getPeerCertificate '\0' handling (CVE-2009-2408 test).

B. Bun Shell ($) — (parallel agent landing corpus tests)

• **$\cmd` segfaults** in the interpreter execution-completion microtask (get_by_idon null); construction + parse work, the completion callback derefs a null/freed object. ~11bun/shell` files.

C. fetch / HTTP client

• redirect + gzip — fixed in c508e00 (NativePromiseContext wiring; see below). fetch-gzip.test.ts 2/3 → 5/0.
• streamed gzip with delay — fixed in c508e00 (same root).
• body-stream.test.ts — the hang is fixed by c508e00; remaining failures now fail fast and are a separate request-body-stream clone bug (reader (clone) + force ReadableStream conversion).

D. HTTP/2 & HTTP/3

• HTTP/2 client — real protocol-impl bugs producing wrong/empty responses (toBe mismatches, "JSON Parse: Missing"). fetch-http2-client.test.ts (58 fail), fetch-http2-adversarial (9).
• HTTP/3 — unported (fetch-http3-*).

E. Deep/unported subsystems

• napi-FFI — crash in cc.test.ts.
• S3Client — s3-stream-cancel-leak segfault; S3 largely parked.
• Bake/HMR — parked; ClientFile.Packed size invariant relaxed for release ([df83921]).
• Worker MessageChannel/BroadcastChannel edge cases — core cross-thread now works (dcb6db6); verify remaining worker tests.

F. Memory-leak tests (triaged on ReleaseSafe 2026-07-07 — build target un-rotted in 55f7140)

• setTimeout-clear-in-callback — ✅ FALSE ALARM: all 3 variants (clear/refresh/repeat) pass on ReleaseSafe; debug-build overhead as suspected.
• text-decoder utf16le output-buffer leak — ✅ FALSE ALARM: both utf-16le and utf-16be pass on ReleaseSafe.
• streams-leak — ✅ FALSE ALARM: passes on ReleaseSafe.
• serve-body-leak — ✅ CLOSED (4ee746c): root cause was the libc mimalloc shim (allocator page retention, not a leak — see forensics comment). Real mimalloc re-attached (Phase 12.2); 7 pass / 0 fail on ReleaseSafe.
• inspect-error-leak — ✅ CLOSED (4ff003d): ZigException.Holder.deinit was a stub that dropped the pin's deferred resetArena — every inspected error left one full transpile in the module loader arena (74MB/100k iters). Now passes with 'RSS increased by 4 MB', exactly real Bun's number.
• node:util test-aborted gc-cleanup — ✅ CLOSED (d459e0d): FinalizationRegistry callbacks never fired AT ALL — JSCScheduler.zig was a no-op placeholder and the two event-loop exports were noop stubs, severing JSC's DeferredWorkTimer delivery chain. Pin's scheduler ported; test-aborted now 5/5 (gc-cleanup passes in 2.5ms).
• (new) HTMLRewriter handler leak — reclassified, NOT a leak: all 58 lol_html_* symbols are noop stubs (lol-html Rust crate unported — link_bun_rust_archive = false); the child panics on the first .on() (else => unreachable on a garbage return at lolhtml_sys/lol_html.zig:253) and the test fails on stderr. Belongs with section E as an unported-library item: link lol_html_c_api (rlibs exist in the Bun build tree), delete the stubs, and restore the pin's HTMLString.toString free (lol_html.zig:623 — latent leak once real lolhtml links).

G. Environmental / infra (mostly resolved)

• Test runner: home test defaults to native bun:test runner (078c659)
• bun:internal-for-testing gated in release (13deb08)
• node v24 + bun v1.3.14 installed via pantry (clears differential-spawn "node not found" failures)
• Build recovery recipe after /tmp wipe (memory: home-build-portability.md)

---

Done this session (context)

signals (db0df4d), native-VM file runner (f296bb6), Worker cross-thread + teardown (dcb6db6, 85aba46), native test runner default (078c659), translateUVErrorToE (188268e), Bun.markdown renderer (2768d9a), MD4 (1279c18), Bun.CSRF (96b8f05), node:tls SecureContext ~40 tests (6cf4a6b), release build + build-recovery (dff7bfa, df83921, 13deb08).

[chrisbbreuer]

✅ A. ALPN — fixed in 428aa2c

Root cause (broader than ALPN): home.zig's jsc.generated namespace is a hand-mirror stand-in for the un-emitted bindgenv2 codegen. Its SSLConfig.fromJS hand-parses cert/key/passphrase/etc but explicitly skipped ALPNProtocols (left alpn_protocols = .none). The real C++ bindgenConvertJSToSSLConfig (which does handle it, incl. typed-array views via IDLArrayBufferRef) is present in the pinned obj but not called — Home routes through the hand-mirror instead.

Consequence: client sockets never called SSL_set_alpn_protos, servers never registered the select callback in time → alpnProtocol === false, no negotiation. The onOpen setup timing (socket.zig 512-519) was fine all along; the config just never carried the protos.

Fix: parse ALPNProtocols in the hand-mirror (string or wire-format buffer/typed-array via asArrayBuffer), store the buffer variant as a borrowed ArrayBuffer copied out synchronously in fromGenerated.

Verified locally: client negotiates http/1.1; multi-proto client ["h2"] vs server ["h2","http/1.1"] → h2; no-ALPN path still connects with alpnProtocol=false.

Note for remaining A items: this hand-mirror is likely the root of other TLS config gaps too — buffer/array cert forms are still .none (see SSLConfigFile.fromJS), which is probably why some cert-chain / addContext scenarios fail. getCipher/getPeerCertificate are separate (post-handshake SSL-state, not config).

Machine caveat: the reference bun (system + pin, both fd0b6f1a2) crashes with index out of bounds: len 4095 on TLS network connects on this macOS 27 box, so bun.sh-based tests (e.g. the connect-suite ALPN case) can't be validated here — used local server+client instead.

[chrisbbreuer]

✅ Buffer/typed-array cert/key/ca — fixed in b3492d3

Follow-up to the ALPN root cause: the same hand-mirror's SSLConfigFile.fromJS only accepted PEM strings and Bun.file() Blobs — a Buffer/typed-array (the common readFileSync(path) result) fell through to .none. So a server given Buffer key/cert had no certificate (handshake timed out) and a client given a Buffer ca couldn't verify the peer.

Now accepts typed-array/ArrayBuffer via asArrayBuffer (view-resolved). BufferValue carries the resolved ArrayBuffer value (borrowed, copied out synchronously) rather than a *JSCArrayBuffer a view can't cast to.

Verified: server w/ Buffer key+cert serves data; client w/ Buffer ca → authorized=true; Buffer certs + ALPN → http/1.1. JS-array cert forms (multiple PEMs in an array) still .none — a smaller remaining gap.

This likely unblocks a broad swath of node:tls tests that pass certs as readFileSync Buffers.

[chrisbbreuer]

✅ Array-form cert/key/ca — fixed in b9551ec

Completes the hand-mirror config-parse thread. SSLConfigFile.fromJS now parses JS-array forms (ca: [pem1, pem2], mixed string/Buffer/Bun.file elements) into an owned GeneratedList; the consumer already supported .array.

Config-parse gaps in jsc.generated (home.zig hand-mirror) are now closed: ALPNProtocols ✅, Buffer/typed-array certs ✅, array certs ✅. Verified: client with ca:[Buffer, string] → authorized=true.

Remaining section-A items are not config-parse — they're post-handshake SSL state (getCipher/getSession/getPeerCertificate) and separate APIs (server.addContext SNI, incomplete cert-chain verification, wrong-passphrase validation).

[chrisbbreuer]

Session progress: config-parse thread closed, getCipher cluster cleared

Three pushed fixes this session — all traced to the same root cause (home.zig hand-mirror jsc.generated dropping unparsed TLS config): ALPN (428aa2c), Buffer/typed-array certs (b3492d3), array certs (b9551ec).

Ripple win: the Buffer-cert fix cleared the entire getCipher/getSession/getProtocol/getEphemeralKeyInfo/getSharedSigalgs/exportKeyingMaterial/isSessionReused cluster — those were never bugs, just symptoms of a cert-less (failed) handshake. All verified locally. Real-pin node-tls-cert.test.ts now runs 25 pass / 3 todo locally (remaining fails are external NODE_EXTRA_CA_CERTS + the machine's bun.sh crash).

New real gap isolated — getPeerCertificate (abbreviated): returns {} (0 own props) even though the cert is valid and the modern getPeerX509Certificate() works. The legacy encoder Bun__X509__toJSLegacyEncoding → JSX509Certificate::toLegacyObject(ncrypto::X509View, globalObject) (src/jsc/bindings/JSX509Certificate.cpp:706) produces an empty object with no exception — a C++/JSC-level discrepancy needing C++ debugging, not a config/Zig fix. Parked for a future session.

Machine caveat reminder: reference bun (system + pin, both fd0b6f1a2) crashes index 4095 on TLS network connects on this macOS 27 box, so bun.sh-based tls tests can't run here — local server+client tests used throughout.

[chrisbbreuer]

Section A (node:tls) — local-test survey after the config-parse fixes

Ran the local (non-external) node:tls suites. Strong state:

file	result
node-tls-server	22 / 0 ✅
node-tls-cert	25 / 0 (+3 todo) ✅
node-tls-connect-hostname-verification	4 / 0 ✅ (servername fix, no regression)
node-tls-create-secure-context-args	5 / 0 ✅
node-tls-internals	2 / 0 ✅
node-tls-no-cipher-match-error	1 / 0 ✅
node-tls-upgrade	1 / 0 ✅
node-tls-context › addContext	pass ✅ (isolated; SNI fix)
ssl-ctx-cache	4 / 1 ⚠️

Remaining local A failure — ssl-ctx-cache: "SSL_CTX is freed once no owners remain (weak cache, not strong)" — a unique-ciphers SecureContext is retained after GC (live count before+1, consistently). SecureContext.finalize is wired to SSL_CTX_free; intern() stores the wrapper in the pin's Bun__SecureContextCache (weak in the pin). So it's a GC/weak-map reclaim subtlety (or Bun.gc(true) not fully collecting in this build), not a config-parse gap — pre-existing, section-F-adjacent. Parked.

The larger node-tls-context / node-tls-connect suites can't be fully scored here — their remaining cases connect to bun.sh/badssl, which crash the reference bun too on this macOS 27 box.

Net section A: ALPN ✅, Buffer certs ✅, array certs ✅, SNI/addContext ✅, getCipher cluster ✅ (parity), getPeerCertificate ✅ (parity). Remaining: the ssl-ctx-cache GC leak + wrong-passphrase validation + detailed-cert chain (shared pin TODO).

[chrisbbreuer]

🚩 Landmark fix — async Bun.serve handlers (c508e00)

Re-diagnosis of section C: the fetch-gzip failures were not a gzip/redirect/connection-lifecycle bug. Root cause: NativePromiseContext.create()/take() (RequestContext.zig's server-side .then() bridge) were soft-linked fn-ptrs that permanently pointed at local stubs — create → .zero, take → null — and the real Bun__NativePromiseContext__create/take in the linked Bun object were never wired.

Effect: when a Bun.serve handler returns a Promise that settles on a later event-loop tick (any timer or async file/network I/O — i.e. every async handler except one resolved by a synchronous microtask), onResolve fired but take() returned null, so the Response was silently dropped and the request hung until the client timed out. Sync/microtask handlers took the .fulfilled fast-path and masked it.

Isolation path: fetch-gzip redirect hang → not redirect (plain redirect OK) → not gzip → not the ArrayBuffer → await of any macrotask in a handler → handler runs to completion but Response never sent → onResolve fires but NativePromiseContext.take returns null → the create/take stubs.

Fix: point the fn-ptrs at the real externs under -Denable_jsc (stubs kept for the JSC-less test gate). This is broad — it unblocks any async handler doing real I/O, so expect improvements well beyond fetch-gzip.

Verified: handlers awaiting setTimeout/fs.promises.readFile/Bun.file().arrayBuffer() now respond; fetch-gzip 5/0; body-stream no longer hangs (remaining fails are a separate body-stream clone bug).

[chrisbbreuer]

⚠️ Methodology: debug-build startup makes subprocess-spawning tests false-fail

Measured: a single home -e (or home run) on the debug build takes 3–4 s to start (160 MB binary + JSC init; release ≈ 250 ms). Many tests do Bun.spawn([bunExe(), …]) and assert within a 5 s timeout — so spawn+startup alone eats the budget, and test.concurrent (10× at once) blows past it.

Confirmed false-fails from this, not real bugs:

• http-server-chunking 10 timeouts — the chunked parser (incl. split \r\n terminators / split chunk-size CRLF) works: the exact subprocess script returns Got: Wiki in ~50 ms via both home run and home -e.
• bun-serve-body-json-async — also Bun.spawn(bunExe()).

Consequence: the debug binary is only a reliable signal for in-process tests. Subprocess-spawning suites (a large fraction of test/js/bun/http and CLI tests) need a ReleaseSafe build to score honestly. Building one now; will re-survey on it. This also unblocks the section-F leak tests, which require release.

[chrisbbreuer]

🔎 New root cause: subprocess stdout not streamed incrementally (Bun FilePoll dispatch)

Investigating spawn-based test failures (#9222, and the pattern "spawn a server fixture → read its URL from stdout → connect") surfaced a real bug, distinct from the debug-startup artifact.

Symptom: proc.stdout from Bun.spawn delivers nothing via for await while the child stays alive — data only arrives when the child exits (pipe closes). Confirmed parent-side: even spawning sh -c 'echo X; sleep 5' (flushes immediately), Home's parent reads nothing until close. So it's not child buffering.

Root: the subprocess pipe reader (SubprocessPipeReader → PosixBufferedReader) registers a FilePoll on the uWS loop's kqueue (registerWithFd does a real kevent64 EVFILT.READ | EV.DISPATCH), and onTick is exported as Bun__internal_dispatch_ready_poll. But the dispatch never fires for these polls — while uSockets primitives (sockets and timers, incl. the await setTimeout handlers fixed in c508e00) work. So Bun FilePoll-based I/O (pipes, fs watch, DNS c-ares) isn't being pumped by the running loop, even though us_poll/us_timer are. A stale comment in SubprocessPipeReader.start ("Home's io.BufferedReader is currently a stub… once the real posix_event_loop FilePoll is wired") points at incomplete FilePoll↔uSockets-loop integration.

Impact: broad — any test that reads a live subprocess's stdout/stderr incrementally (large slice of test/js/bun/http, CLI, and node child_process suites). High priority, but a deep event-loop fix (need to confirm the loop the FilePoll registers on is the one being run, and that the pinned uSockets dispatches tagged Bun FilePolls to Bun__internal_dispatch_ready_poll).

Landed this session regardless: tls-option validation (ba67d6c) — Bun.serve({tls: <non-object>}) now throws TLSOptions must be an object.

[chrisbbreuer]

🔬 Refined: subprocess-stdout streaming — FilePoll dispatch works; break is in the reader→ReadableStream layer

Instrumented registerWithFd + onTick in a debug build and ran a sh -c 'echo X; sleep 5' child:

• registerWithFd succeeds (rc=0 errno=SUCCESS, real kevent64 on the uWS loop's kqueue).
• onTick fires (is_filepoll=true) when the pipe becomes readable, and onUpdate matches the BufferedReader owner tag → calls onPoll → read.

So the FilePoll dispatch is not the bug (my earlier hypothesis). Traced the Zig side end-to-end and it all looks correct: SubprocessPipeReader → ReadableStream.fromPipe transfers the reader into a FileReader.Source (reader.from(..) rebinds parent, keeps the Source's FileReader-typed vtable, which does have onReadChunk; FilePoll ownership transfers via setOwner).

Remaining suspect (deep): the data read by onPoll isn't reaching the JS for await (proc.stdout) until EOF — the break is in the final FileReader.Source ↔ C++ ReadableStream onPull/enqueue propagation (or the read is buffered and only flushed on onReaderDone). The observed tight re-arm/re-fire loop on one fd suggests data isn't being consumed on the streaming path. Needs a probe of whether FileReader.onReadChunk is actually invoked and whether the C++ stream propagates enqueued chunks incrementally — a deep webcore/streams fix, deferred.

Net: still a real, high-impact bug (server-fixture spawn tests), now narrowed to the webcore streaming layer rather than the event loop.

[chrisbbreuer]

✅ FIXED — subprocess stdout streaming (b20f4fa): macOS MSG_DONTWAIT was 0x40

Cracked the deep bug from the prior comments. Root cause is a one-line constant: bun.c.MSG_DONTWAIT was hardcoded to 0x40 (the Linux value). On Darwin, 0x40 is MSG_WAITALL and MSG_DONTWAIT is 0x80.

So every nonblocking recv() on macOS was silently passing MSG_WAITALL — asking the kernel to block until the entire read buffer was filled. On a nonblocking socketpair that returns EAGAIN whenever fewer bytes are available than the (large) buffer. The subprocess stdout/stderr reader therefore got EAGAIN despite kqueue reporting bytes ready, spun re-arming the poll, and only flushed on EOF.

Diagnosis chain (debug-instrumented): FilePoll dispatch fires → onPoll runs with fileType=socket, size_hint=9, streaming=true → recv returns errno 35 (EAGAIN) → swapping to read() delivered the 9 bytes and onReadChunk fired → traced the EAGAIN to MSG_WAITALL.

Fix: MSG_DONTWAIT = if (isMac) 0x80 else 0x40. Verified: for await (proc.stdout) streams incrementally from both a sh child and a live Home child; socket receive unaffected; bun-serve-body-json-async (#9222) 0/1 → 1/0.

Broad impact: fixes all nonblocking recv/send on macOS — unblocks the large "spawn a server fixture → read its stdout → connect" test category across test/js/bun/http, CLI, and node child_process suites. Also retroactively explains a chunk of the earlier http-server-chunking-style spawn timeouts.

[chrisbbreuer]

Release-build survey after the MSG_DONTWAIT fix — strong state

Re-ran the spawn/http suites on a fresh ReleaseSafe binary:

suite	result
bun-serve-static	34 / 0 ✅
bun-server	42–44 / 0–2 (the 0–2 are flaky GC-timing)
serve-listen	27 / 0 ✅
bun-serve-propagate-errors	1 / 0 ✅
tls-keepalive	6 / 0 ✅
bun-serve-body-json-async (#9222)	1 / 0 ✅ (MSG_DONTWAIT)
streams.test.js	68 / 0 ✅
http-server-chunking	11 / 0 sequential ⚠️ concurrent-only timeouts

http-server-chunking resolved as environmental: all 11 tests pass when run sequentially. The failures only appear under test.concurrent (10 subprocesses at once), where 10 × ~83 MB home spawns + server + client saturate this machine's 5 s budget. Not a Home correctness bug — the chunked parser (split \r\n terminators, split chunk-size CRLF, invalid-byte rejection) is correct. This is the "resource-exhaustion → false hang" class; it'll pass on CI.

Net: the runtime is in strong shape on release. The MSG_DONTWAIT fix (subprocess streaming) + NativePromiseContext (async handlers) cleared the two broad event-loop-ish blockers. Remaining real (non-environmental) items are narrower and deeper: HTML bundling (bun-serve-html 404s), body-stream typed-array clone edge case, ssl-ctx-cache GC reclaim, HTTP/2 protocol, shell segfault, napi.

[chrisbbreuer]

🔴 CRITICAL (release-only): flaky segfault in in-process serve+fetch

Found while surveying on the ReleaseSafe binary. The debug build is stable; the release build intermittently segfaults (null+0xb0 deref) on the basic in-process Bun.serve + fetch(server.url) pattern.

Isolation (release binary):

• serve + sync handler + in-process fetch → crashes ~1 in 3 runs (flaky)
• serve + async handler (micro or macro) + in-process fetch → OK
• serve + async body stream + in-process fetch → crashes
• serve + external curl`` (no in-process client) → always OK
• response.test.ts (no serve/fetch roundtrip) → 14/0

So it's a timing-sensitive race when the fetch client and the serve server share one event loop, exposed by release-build speed. Real pin tests hit it: fetch-gzip, fetch-args, body-stream segfault on release (all were green on debug). bun-serve-static (34/0) and serve-listen (27/0) happen to dodge it.

Not attributable to this session's fixes: the crash is on the synchronous render path + in-process client; my changes touch config-parse (TLS), NativePromiseContext (async only — and async works here), and MSG_DONTWAIT (recv, which fetch doesn't use). All 8 fixes are debug-verified. Most likely a pre-existing latent event-loop race that only manifests under release timing.

Why it matters: this is probably the #1 reliability blocker for scoring the pin suite on release — a large fraction of tests do in-process serve+fetch. Needs an ASAN / debug-symbol release build to get a real stack trace (the optimized trace only shows a mis-unwound us_internal_dispatch_ready_poll). Flagging as critical; deferring the fix since it needs the ASAN toolchain, not a source guess.

[chrisbbreuer]

Correction: the release race is general (not sync-specific), ~50-60% repro

Ran 12× each on the release binary:

• sync handler + in-process fetch → 7/12 crash
• async handler + in-process fetch → 6/12 crash

So both crash at the same rate — my earlier "sync crashes, async works" was flaky luck. This conclusively rules out the NativePromiseContext change (were it the cause, async would crash more, not equally). It's a general ~50-60% flaky segfault whenever a fetch client and its Bun.serve server run on the same event loop (loopback re-entrancy), only under release-build timing. External-client (curl) never crashes; debug never crashes.

Confirmed pre-existing and independent of this session's 8 fixes. Top reliability blocker for scoring the pin suite on release; needs an ASAN release build for a real trace. Practical workaround for now: score correctness on the debug build (stable), which is how all 8 fixes this session were verified.

[chrisbbreuer]

✅ Primary release crash fixed (545c904) — HTTP Decompressor null-deref

Cracked the flaky release segfault to an exact line via lldb: ZlibReaderArrayList.deinit(this=0x0) on the HTTP Client thread. The Decompressor union's first tag is .zlib, so all-zero memory reads as .zlib with a null reader; AsyncHTTP.client is HTTPClient = undefined until init, and release-mode undefined can be zero, so InternalState.reset → decompressor.deinit over the not-yet-initialized state derefs null.

Guarded deinit against the null reader (teardown-only, correctness unaffected; a live reader is never null). Verified on release: rc_sync 0/15 crashes (was ~8/15), fetch-gzip 5/0, fetch-args 47/0 — all previously segfaulted.

A separate release crash remains: body-stream-excess now faults at address 0x0 (vs the decompressor's 0xb0) — different bug, investigating next. The deeper root (why HTTPClient teardown runs over undefined/freed state — a cross-thread lifecycle issue) is follow-up; the guard makes it non-fatal.

[chrisbbreuer]

✅ Bun Shell core crash fixed (4166e25) + blob resolved

blob (was 15/1): the failure was an environmental leaked bun process holding port 3000 (from earlier differential runs), not a Home bug — 16/0 after killing it.

body-stream-excess / section B (shell): the JSC get_by_id-on-null crash was the Bun Shell, not body-stream. Cracked it via step-probing to JSArrayIterator's slow-path JSObject.getIndex, a stub returning error.JSError with no pending exception → the exception machinery deref'd the absent exception → segfault. A tagged template's strings.raw array is frozen (CopyOnWrite, skips the fast contiguous-vector path), so every $cmd`` crashed in createParsedShellScript → shellCmdFromJS → arrayIterator.next(). Wired the real `jsc.JSObject.getIndex` under `-Denable_jsc`.

Now working: $echo hello, substitutions (`$`echo ${42}), multi-arg builtins — the whole tagged-template + arg path. This also fixes any test that shells out via $.

Still broken (separate, deeper):

• External commands ($ls, `$`curl) crash with 0xdeadbee0 (use-after-free poison) in the shell subprocess-execution path — distinct from the builtin path. Blocks body-stream-excess (uses $curl``) and most test/js/bun/shell/*.
• $.braces returns a cyclic object (native binding mis-wired), not the expected expansion array.

Net: the fundamental shell (parse + builtin exec) is unblocked; external-command exec and the $.braces/lexer APIs are the next shell targets.