[robobun]

Problem

• A script pipes a type: "direct" ReadableStream into stdout with Bun.write and awaits controller.flush(). The reader exits. An ASAN build reports heap-use-after-free in PosixStreamingWriter<FileSink>::close (src/io/PipeWriter.rs:1076), called from _on_error.
• _on_error calls Parent::on_error, then self.close(). FileSink::on_error rejects the flush promise, and the rejection handlers release the last refs on the sink. The writer is a field of the sink.

Fix

• Both POSIX pipe writers hold a ref on the parent across on_error and close(): in _on_error, and in the failed-registration arm of PosixStreamingWriter::register_poll. Nothing uses the writer after close().
• ParentKeepAlive is the RAII guard. The parent macros stamp its trait, PosixWriterParent, from the ref_ and deref that each parent already passes for Windows. The arm of register_poll is a #[cold] function, so register_poll still inlines into write.
• Verified: test/js/bun/util/filesink.test.ts (main's ASAN build fails the new test). Also the terminal, shell and spawn suites.
• Self-reviewed: 3 concerns raised, 3 addressed (see Notes).

Background

• A pipe writer drains bytes to an fd and reports to its refcounted parent (FileSink, Terminal, the shell IOWriter, StaticPipeWriter) through on_write, on_error and on_close.
• Bun.write(dest, stream) pumps into a FileSink with no JS wrapper. Two refs hold it: the pump's, and a keep-alive ref that on_close releases.
• Considered a guard inside FileSink::on_error: it ends before the writer calls close(). The writer's guard covers every parent.

Downsides

• A failed write costs one more increment and decrement of the parent's refcount.
• A write that succeeds costs nothing new: 346 instructions in FileSink::write for a 64-byte write, on main and here. Text grows by 768 bytes.
• Not changed: the Windows writers, and uses of a writer after on_write (see Notes).

Notes

This is a rebase of the July version of this PR. What changed in it:

• Gone, because main has them now: the FIFO redirect change in shell/Builtin.rs and its test (shell: route FIFO redirect targets through the pollable IOWriter path #34696), drain_buffered_data that returns the error and does not call on_error (spawn: release the buffer-stdin writer's start() ref when its write fails on POSIX #37774), the release of the start() ref of StaticPipeWriter after a failed write (spawn: release the buffer-stdin writer's start() ref when its write fails on POSIX #37774 does it in on_close), and PosixBufferedWriter::register_poll, which now reports a failed registration through _on_error.
• Gone, because the code is gone: the macOS libinfo hunk in dns.rs.
• Dropped: the STATIC_PIPE_WRITER dispatch shim (it existed for the on_error release that spawn: release the buffer-stdin writer's start() ref when its write fails on POSIX #37774 replaced, and io: report to pipe writer parents through raw pointers, release StaticPipeWriter through its backref #37755 reworks that chain), the keepalive in IOWriter::on_write_pollable (the poll dispatch already holds one, and on Windows the in-flight write holds one), and the comment edits in shell/IOWriter.rs and shell/subproc.rs.
• Changed: the guard is a named Drop type, not a scopeguard closure. ref_ and deref are on one supertrait, not on each POSIX parent trait.

Repro (Linux x64, debug ASAN build):

cat > sink.mjs <<'JS'
await Bun.write(Bun.stdout, new Response(new ReadableStream({ type: "direct",
  async pull(c) { c.write(new Uint8Array(1 << 20)); await c.flush(); c.close(); } })));
JS
bun sink.mjs | (sleep 0.1; head -c 262144 > /dev/null)

main at 11c41c6: 3 of 3 runs report the use-after-free. This branch: 0 of 3, exit status 1 with one EPIPE: broken pipe, write, the same as a release build.

heap-use-after-free, READ of size 1, 121 bytes inside of a 344-byte region
 #0 PosixStreamingWriter<FileSink>::close       src/io/PipeWriter.rs:1076
 #1 PosixStreamingWriter<FileSink>::_on_error   src/io/PipeWriter.rs:790
 #3 PosixPipeWriter::on_poll                    src/io/PipeWriter.rs:202
freed by
#17 FileSink::run_pending                       src/runtime/webcore/FileSink.rs:362
#18 FileSink::on_error                          src/runtime/webcore/FileSink.rs:483
#20 PosixStreamingWriter<FileSink>::_on_error   src/io/PipeWriter.rs:789

How the last ref goes away inside on_error. run_pending rejects the flush promise and runs the microtasks. pull() rejects, so the promise of the pump rejects and on_reject_stream runs. It adopts the ref of the pump and calls handle_reject_stream, which calls writer.close(). _on_error already closed the fd without a report, so this close() delivers on_close, and on_close releases the keep-alive ref. on_reject_stream then drops the ref of the pump, and the guard in run_pending drops the last one.

With the change the close() at the end of _on_error finds the handle closed and reports nothing. The sink gets one on_error and one on_close. In the release build the flag closed_without_reporting is read from memory again after the on_error call (checked in the disassembly of __bun_run_file_poll), so a value from before the call is not used. The guard is three instructions there: incl, then decl and jne in front of the cold call that frees the sink.

Cost of a write that succeeds. register_poll runs on every buffered write. With the guard inline in its error arm, the compiler stopped inlining register_poll into write. The arm is out of line now. I counted user instructions from the entry of FileSink::write to its return with gdb (stepi), over 128 consecutive calls, in release builds on the same base (5a183c1). The script writes 64 bytes to proc.stdin in a loop and calls flush() every 64 writes.

build	buffered write	write that reaches 4096 bytes	average
main	346	386	346.6
guard inline in the arm (f29b67c)	363	384	363.3
#[cold] arm (this head)	346	384	346.6

size of the stripped binary: text 80,677,348 on main and 80,678,116 here. Both files are 80,844,360 bytes. perf and valgrind are not available in my container, so I have no count for a whole process.

The test. A write error reaches the sink from two places. One is the poll callback (this bug). The other is the flush that the auto-flusher of the sink makes after each microtask drain. That one has its own guard and does not reach _on_error. So the read end has to close while the child waits in its poll. The test reads 4 x 64 KiB from a FIFO, waits 10 ms, and then closes. Each refill shows that the child ran, and the wait lets it finish the turn that made the last refill. On the debug ASAN build of main the test fails 5 of 5 times alone and 2 of 2 times inside the whole file. The same sequence in a script, 6 at a time, reports the use-after-free 18 of 18 times. A fixed build gives the same output on both paths, so the wait cannot make the test fail there.

An earlier version closed in the same step as its last read. That finds the bug only when the close lands before the next write of the child. A fast build often writes first, and then the flush at the end of that turn reports the error.

Not changed: Windows. The Windows writers take a ref on the parent for each write in flight and release it after the completion callback. That covers this order there. The three arms of WindowsStreamingWriter::process_send for a write that fails at once call on_error and then close() with no ref of their own. I found no way to reach them with a promise pending, and I cannot run Windows.

Not changed: the free under &mut self. The release of the guard can free the parent while _on_error(&mut self) is on the stack. Main already frees at this position (StaticPipeWriter::on_close, FileSink::on_close), and #37755 moves that chain to raw pointers.

Not changed: uses of the writer after on_write. There are nine on POSIX: six in the write* functions of PosixStreamingWriter (on_write, then register_poll), the Pending arm of on_poll for each of the two writers, and PosixBufferedWriter::_on_write (on_write, then close() at end of file). I found no input that frees the parent inside them. Only facts about each parent prevent it, and no written rule does. A guard there adds a ref and a deref to every write. #37755 reworks that chain and is the place for the rule.

Self-review. Three concerns survived, and each is handled. The SAFETY note in StaticPipeWriter::on_close said that its deref frees the writer on POSIX. With the new ref it does not, so the note is updated, and so is the comment in FileSink::on_error. Both POSIX parent traits now say what on_error may release. The unguarded sites are listed above. #37755 rewrites the same three functions: the one that lands second has to carry the ref.

Checks. cargo fmt, cargo clippy for bun_io, bun_spawn and bun_runtime, cargo check for x86_64-pc-windows-msvc and aarch64-apple-darwin. On the debug ASAN build: filesink.test.ts (78 pass), terminal.test.ts (99), console-write.test.ts (5), shell/file-io.test.ts (27), shell-blocking-pipe.test.ts (2), shell-write-fault.test.ts (1), spawn-stdio-syscall-error.test.ts (17), spawn-stdin-readable-stream.test.ts (37), spawn-stdin-pipe-fd-leak.test.ts (4). spawn.test.ts ran on an overloaded host: 170 pass and 8 timeouts at 5 s here, 172 pass and 6 timeouts in the same groups on the build of main.

---

no test proof · iteration 10 · platform-specific test(s) that do not run on this machine, deferring to CI, which covers all platforms: test/js/bun/util/filesink.test.ts

[robobun]

^{Updated 8:12 AM PT - Oct 1st, 2026}

❌ @robobun, your commit 6861b25 has 1 failures in Build #122410 (All Failures):

• test/js/bun/spawn/spawn.test.ts - code 1: stdout reader of an unref'd child and process lifetime > an idle reader stopped at the highwater … on 🐧 13 x64-asan

---

🧪   To try this PR locally:

bunx bun-pr 34697

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

bun-34697 --bun

[github-actions]

Found 3 issues this PR may fix:

1. --env-file and Bun.file().text() silently drop data on FIFOs; breaks 1Password's local-env-file integration #30520 - --env-file and Bun.file().text() silently drop data on FIFOs; the PR fixes the root cause of FIFO pollable flag being discarded in shell builtin redirections
2. Bun Shell hangs with git show command, spawnSync from node:child_process succeeds #26580 - Bun Shell hangs with git show command; the pipe buffer filling + incorrect non-pollable routing could cause this class of shell hang
3. FileSink.write incoherencies #12194 - FileSink.write incoherencies when piping large data; the PR's keepalive hardening of POSIX pipe writer error paths addresses erratic behavior writing to subprocess stdin pipes

If this is helpful, copy the block below into the PR description to auto-close these issues on merge.

Fixes #30520
Fixes #26580
Fixes #12194

🤖 Generated with Claude Code

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

Walkthrough

Changes

POSIX pipe lifetime and shell I/O

Layer / File(s)	Summary
Writer error dispatch and parent lifetime src/io/PipeWriter.rs	POSIX writers add intrusive parent pinning around error callbacks, propagate buffered errors through polling, and update generated vtable shims.
Terminal parent refcount wiring src/runtime/api/bun/Terminal.rs	Terminal implements the new POSIX streaming writer refcount hooks.
Pollable shell redirection and callback keepalive src/runtime/shell/..., test/js/bun/shell/shell-blocking-pipe.test.ts	Shell redirects use detected pollability, callbacks retain IOWriter, subprocess ownership comments are updated, and named-pipe backpressure is covered by a regression test.
Static pipe dispatch and error cleanup src/runtime/dispatch.rs, src/spawn/static_pipe_writer.rs	Static pipe polling uses an explicit lifetime-safe dispatch wrapper, and non-Windows static pipe errors conditionally release the reference held by start().

DNS poll registration failure

Layer / File(s)	Summary
libinfo poll failure completion src/runtime/dns_jsc/dns.rs	macOS DNS lookup now deinitializes failed poll registration and completes the request with an error callback.

Possibly related PRs

• oven-sh/bun#34696: Both changes update POSIX FIFO redirection and pollable writer behavior.

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 clearly describes the primary change: POSIX pipe writers retain a reference to their parent during error handling until close() completes.
Description check	✅ Passed	The description explains the problem, fix, scope, limitations, regression scenario, and verification results. It does not use the exact template headings, but it provides the required information in e…

---

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

[coderabbitai]

Actionable comments posted: 2

🤖 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/runtime/dns_jsc/dns.rs`:
- Line 303: Replace the silent `let _ = err` handling in the `register_with_fd`
failure path with a scoped debug log that includes the registration error, then
preserve the existing callback behavior.

In `@test/js/bun/shell/shell-blocking-pipe.test.ts`:
- Around line 67-76: Update the blocking-pipe test’s drained promise around the
reader and process wait: when proc.exited returns a non-zero exit code, destroy
the reader so its error/close path rejects or settles instead of waiting
indefinitely for FIFO EOF. Await the reader completion together with stderr,
stdout, and proc.exited, while preserving successful-exit draining behavior and
wiring reader failure events to rejection.

🪄 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: 6bbbdd85-5983-4bbd-a4c2-78c449bcfffb

📥 Commits

Reviewing files that changed from the base of the PR and between 98f6649 and 28052d4.

📒 Files selected for processing (7)

• src/io/PipeWriter.rs
• src/runtime/api/bun/Terminal.rs
• src/runtime/dns_jsc/dns.rs
• src/runtime/shell/Builtin.rs
• src/runtime/shell/IOWriter.rs
• src/runtime/shell/subproc.rs
• test/js/bun/shell/shell-blocking-pipe.test.ts

[github-actions]

This PR may be a duplicate of:

1. shell: route FIFO redirect targets through the pollable IOWriter path #34696 - Both PRs fix the same FIFO redirect panic in Builtin.rs by passing the computed pollable value to IOWriter::init instead of a hardcoded cfg!(windows), and overlap in IOWriter.rs changes

🤖 Generated with Claude Code

[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 `@test/js/bun/shell/shell-blocking-pipe.test.ts`:
- Around line 84-91: In the blocking-pipe test, move the exitCode failure check
before the combined expect assertion so child stderr is surfaced when the
process fails. Keep the successful-result assertion focused on stdout and
receivedLen (with exitCode as appropriate), and remove the now-unreachable
post-assertion throw.

🪄 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: 24465161-50cb-455e-b61d-706e4eb9e8fc

📥 Commits

Reviewing files that changed from the base of the PR and between d652eae and d208073.

📒 Files selected for processing (2)

• src/spawn/static_pipe_writer.rs
• test/js/bun/shell/shell-blocking-pipe.test.ts

[robobun]

This comment described the July version of this PR (f0036f3, build #76593). That version is no longer in the PR. The PR was rebased on 2026-09-30 and is now one change. The PR body and the rebase comment describe it.

A correction to what this comment said before:

• It said that the July test passed on every lane. The test was skipped on Windows. For the POSIX lanes, the pass was inferred from the list of failures.
• It called the other first-attempt failures flaky before I had read them. Two of the files, filesink.test.ts and spawn-stdin-pipe-fd-leak.test.ts, test the pipe writers that the July version changed. I have read three of those four failures now. They are file descriptor count assertions that passed on retry. I did not find out whether the July diff contributed.

Checked again on 2026-10-01 with the script in the PR body, Linux x64, debug ASAN builds:

• main at 367d939 (2026-09-18): heap-use-after-free in PosixStreamingWriter<FileSink>::close, called from _on_error, in 3 of 3 runs.
• this branch at b50d318: exit status 1 with EPIPE: broken pipe, write and no ASAN report, in 3 of 3 runs. I did not run the commits after 0fb95d1.

[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/runtime/dispatch.rs`:
- Around line 704-728: Restore Windows compatibility for the static pipe writer
polling arms in the dispatch match, including STATIC_PIPE_WRITER,
SHELL_STATIC_PIPE_WRITER, and SECURITY_SCAN_STATIC_PIPE_WRITER. Either
conditionally exclude these arms on Windows or provide a Windows
implementation/shim for bun_spawn::static_pipe_writer::on_poll, ensuring all
referenced symbols resolve on every target.

🪄 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: f2fd94e6-1aaa-4ef7-95d6-58e2a6f19bf9

📥 Commits

Reviewing files that changed from the base of the PR and between d208073 and bd159eb.

📒 Files selected for processing (3)

• src/runtime/dispatch.rs
• src/spawn/static_pipe_writer.rs
• test/js/bun/shell/shell-blocking-pipe.test.ts

[Jarred-Sumner]

Can you use an RAII wrapper

[robobun]

Done in f0036f3:

• PosixBufferedWriter/PosixStreamingWriter now have a parent_keepalive() helper that bumps Parent::ref_ and returns a scopeguard whose Drop runs Parent::deref (matching the existing scopeguard::guard(this, |s| Self::r_deref(s)) pattern the Windows writer paths already use). The four call sites are now just let _keepalive = self.parent_keepalive();.
• static_pipe_writer::on_poll switched to bun_ptr::ScopedRef::new(parent) directly since StaticPipeWriter<P> is #[derive(RefCounted)].

Couldn't use bun_ptr::ScopedRef in PipeWriter.rs itself because the Parent generic is not bounded by AnyRefCounted (the shell IOWriter parent is Arc-backed, not intrusive-refcounted), so the trait-method-based scopeguard is the tight fit there.

[robobun]

Rebased onto main (5a183c1) and force-pushed as f29b67c. The PR is now one change and one test: both POSIX pipe writers hold a ref on their parent from on_error until close() returns.

Why now. On an ASAN build, the script below reads the stdout sink after it is freed. The read is in PosixStreamingWriter::close, called from _on_error. The free is inside the Parent::on_error call one line above it.

cat > sink.mjs <<'JS'
await Bun.write(Bun.stdout, new Response(new ReadableStream({ type: "direct",
  async pull(c) { c.write(new Uint8Array(1 << 20)); await c.flush(); c.close(); } })));
JS
bun sink.mjs | (sleep 0.1; head -c 262144 > /dev/null)

How I reproduced it. Debug ASAN build of main at 11c41c6, Linux x64: 3 of 3 runs report heap-use-after-free. With this branch the same runs exit with one EPIPE: broken pipe, write. The new test in test/js/bun/util/filesink.test.ts fails on the ASAN build of main with that report and passes here.

What left the PR. Main already has the FIFO redirect change (#34696) and the StaticPipeWriter changes (#37774), and the macOS libinfo code is gone. The Notes in the PR body list the rest.

The guard is now a named Drop type (ParentKeepAlive), for the review comment about an RAII wrapper.

[claude]

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

Beyond the inline nit on the test's EAGAIN loop, I also checked the new PosixWriterParent stamping for conflicts: the #[cfg(unix)] / #[cfg(not(windows))] gates match the sibling Posix*WriterParent impls each macro already emits, no parent invokes both macros (so no duplicate impl), and Terminal's hand-written impl carries the same #[cfg(unix)] gate as its existing PosixStreamingWriterParent impl. I also looked at the three PosixBufferedWriter/PosixStreamingWriter _on_error and register_poll sites for a path where the guard is dropped before close() returns — each binds _keep_alive in the enclosing scope so it outlives the trailing close().

Extended reasoning...

This rebase adds a PosixWriterParent supertrait and an RAII ParentKeepAlive guard to the POSIX pipe writers in src/io/PipeWriter.rs, stamps the impl via the two parent macros and a hand-written Terminal impl, and adds a FIFO-based FileSink regression test; it touches no auth, crypto, or input-parsing surface. It is unsafe refcount/lifetime code with an outstanding CHANGES_REQUESTED review from a maintainer predating this push, and one verified test-robustness nit is posted inline, so this is not an approve.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

Still open from earlier reviews (1):

• Unresolved: 1 minor or pre-existing.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[claude]

Code review completed

Nothing new to post: everything this review found is already covered by existing comments on this pull request or didn't merit a separate one.

[robobun]

CI on 6861b25 (build #122410) has one failed job. What I checked for each failure:

• test/js/bun/spawn/spawn.test.ts, an idle reader stopped at the highwater mark does not keep the process alive, x64-asan: fails on every retry. It tests the stdout pipe reader, and the child writes with fs.writeSync, so the pipe writers of this PR are not in it. The same failure is on main and on unrelated PR builds.
• test/js/bun/console/console-write.test.ts, an awaited console.write rejects with EPIPE when the reader has hung up (several arguments): failed in the parallel batch on four lanes and passed alone. The output is caught EPIPE and then an unhandled EPIPE. console.write: restore the implementation from before #43649 #44351 describes this failure as flaky on main. It restored the old console.write there and made this test a todo. This branch is based on 5a183c1, which is before console.write: restore the implementation from before #43649 #44351, so its CI still runs the test. A rebase onto current main removes it.
• The other entries passed on retry: four on Windows lanes, fetch-leak.test.ts and serve-body-leak.test.ts (memory thresholds), node-tls-server.test.ts (49 of 50 connections counted), build-toolchain-identity.test.ts, and structuredClone-classes.test.ts (a test worker crash on alpine x64 that is also in builds of unrelated branches).

This diff does not take part in the console.write failure. console.write keeps its sink in a slot of the console object, so the ref that this PR takes in _on_error is never the last one there, and the PR changes nothing else on that path. The entry is on 2 to 4 lanes in each of the last four builds of this PR. For comparison, 21 finished builds of unrelated branches from before #44351 (#122030 to #122059) have it on 0 to 2 lanes each, 16 of them on at least one, and #122064 has it on 5.

test/js/bun/util/filesink.test.ts, which has the test of this PR, has no failure entry in this build.

[Jarred-Sumner]

This is Claude (an AI assistant) commenting on Jarred's behalf.

While putting #46021 together we checked this against main, and the crash it fixes no longer happens there. Closing. Please reopen it if that's wrong.