bake: release the app plugins cell when the dev server is torn down

[robobun]

Problem

• Every dev server created by Bun.serve({ app: { framework, plugins } }) leaks its native plugin cell (BundlerPlugin in heapStats()) after teardown, and with it every setup() / onLoad / onResolve closure registered on it. Stopping four such servers leaves four cells on 1.4.0-canary.
• The same cell leaks when Bun.serve() throws after creating it: a plugin's setup() throwing, or dev server init failing (for example EMFILE while initializing file watcher).
• Cause: the cell is GC-protected and held as a raw pointer. The only release was in the parsed options' destructor, but the server moves the options into the dev server first, and the dev server never released what it took over.

Fix

• The cell is held in an RAII wrapper whose Drop releases it, so whichever struct holds it when it goes away (the parsed options or the dev server) releases it exactly once.
• The dev server's slot becomes an enum: Owned for the app's own cell, Borrowed for the server's [serve.static] plugins, which the server releases. The borrowed arm is only filled when the app declared no plugins, so it never displaces an owned cell.
• Dev server init moves the options into the server struct only after the fallible steps, so an early error drops them, and the cell, on the caller's side.
• Releasing on dev server drop is safe because the cell is only read when a bundle starts, and the server drops the dev server after it has stopped and drained. The wrapper is the same type Bun.serve: release the [serve.static] plugin cell when the server is freed #37805 adds, so either merge order is clean.
• Verification: a new test runs each of the three paths in its own process and counts cells surviving a full GC. Each path leaks 1 cell on 1.4.0-canary and 0 with this PR; the other reported fields are unchanged.

Background

• app.plugins and framework.plugins are collected into one native JSBundlerPlugin object (the "cell") that every bundle of the dev server consults. Bun protect()s it from JSC's GC, so it and everything it references live until something calls destroy, which tombstones and unprotects it.
• Serve options are parsed into a Rust UserOptions struct. Creating a dev server moves the bundler options out of it, so cleanup left in UserOptions no longer sees them.
• An app that declares no plugins makes the dev server borrow the server's [serve.static] plugins, a cell the server owns and releases, so the slot has to tell an owned cell from a borrowed one.
• DevServer::init fills a MaybeUninit box field by field. On an error before the box is marked initialized, fields already written are not dropped, so anything that must be released on failure has to stay outside the box until the fallible steps are done.
• Each dev server takes a file watcher (inotify) instance, a per-user limit returned only on process exit, which is why the test runs each case in a separate process.

Original description

What

The POSIX ready-poll dispatch chain held the poll being dispatched as a reference for the whole time its owner ran (line numbers on main):

// src/io/posix_event_loop.rs
let file_poll: &mut FilePoll = unsafe { &mut *tag.as_file_poll() };          // Bun__internal_dispatch_ready_poll, :1497
pub(crate) fn on_kqueue_event(&mut self, kqueue_event: &KQueueEvent)            // :351
pub(crate) fn on_epoll_event(&mut self, epoll_event: &epoll_event)              // :370
pub(crate) fn on_update(&mut self, size_or_offset: i64) {                       // :434
    unsafe { __bun_run_file_poll(self, size_or_offset) };
}

// src/runtime/dispatch.rs, __bun_run_file_poll
let poll_ref = unsafe { &mut *poll };                                            // :660
resolver.on_dns_poll(unsafe { &mut *poll });                                     // :744
// src/runtime/dns_jsc/dns.rs
pub(crate) fn on_dns_poll(&self, poll: &mut FilePoll)                           // :4786

Same receiver-shape class as #37681, #37778 and #37803. No crash is known from it.

Why it is wrong

The &mut self of on_kqueue_event / on_epoll_event and of on_update, and the &mut FilePoll argument of on_dns_poll, are reference arguments: protected until those calls return, and the owner runs inside them. The owner does not use those references. It reaches the same slot through the pointer it keeps itself (FilePollRef, PollerPosix::Fd, the resolver's poll map), on the normal path, not only on teardown:

• Every reader poll is registered one-shot (FilePollRef::register_with_fd passes OneShotFlag::Dispatch), so on_update sets NeedsRearm and the owner's re-arm during the dispatch reads and clears it again (register_with_fd_impl, unregister_with_fd_impl) through its own pointer. The flag exists to be passed from this frame to the owner's call underneath it.
• An owner that is finished deinits the slot from inside the dispatch: pipe EOF (PollOrFd::close_impl -> FilePollRef::deinit_force_unregister), process exit (Process::on_exit -> close -> PollerPosix), and c-ares closing a socket, which happens inside the Channel::process call that on_dns_poll makes while its &mut FilePoll argument is live (on_dns_socket_state also re-registers the same poll through the map on every read/write transition).

Those are reads and writes through a pointer foreign to the protected references further up the stack, which both aliasing models reject (the protector rule the sibling PRs quote; rustc also marks the arguments noalias). FilePollRef::inner and PollerPosix::fd_poll_mut both document the &mut FilePoll they hand out as the only live reference to the slot; during a dispatch that was not true. It is latent today because nothing on the chain reads the slot after the owner returns, so there is nothing observable to assert on.

Fix

The chain carries the pointer Pollable decodes all the way down, the shape __bun_run_file_poll(poll: *mut FilePoll) and PosixBufferedReader::on_poll(this: *mut Self) already have:

pub(crate) unsafe fn on_kqueue_event(this: *mut FilePoll, kqueue_event: &KQueueEvent)
pub(crate) unsafe fn on_epoll_event(this: *mut FilePoll, epoll_event: &epoll_event)
pub(crate) unsafe fn on_update(this: *mut FilePoll, size_or_offset: i64)
pub(crate) unsafe fn on_dns_poll(&self, poll: *mut FilePoll)

The entry point reads IgnoreUpdates through a statement-scoped access and passes the pointer on; update_flags, the NeedsRearm update, the kqueue syslog! and generation-number debug_assert!, and __bun_run_file_poll's owner/hup reads become statement-scoped accesses; the DNS arm passes poll itself, and on_dns_poll reads fd / is_readable() / is_writable() into locals before process and does not touch the poll afterwards. Same operations in the same order, so no behaviour change.

The contract the chain relies on is only that the slot is live when each frame is entered: nothing on the chain reads it after the owner returns, so the comments say that rather than anything about the slot staying allocated for the duration of the call (deferred frees run from the after-tick callback, which a nested tick inside an owner's JS would also run).

Overlap with #37803: that PR converts the owner's side of the same contract (FilePoll::deinit* and its callers) and, to get there, also converts on_dns_poll and the __bun_run_file_poll reads; it leaves the four frames in posix_event_loop.rs to this PR. The two PRs therefore both touch __bun_run_file_poll and on_dns_poll, and a test merge conflicts in exactly those two functions (posix_event_loop.rs auto-merges). That is deliberate: whichever lands second rebases and takes either side of each conflict, and the lint below passes with both (checked with #37803's versions of dispatch.rs and dns.rs dropped onto this branch). An earlier revision of this PR instead allowlisted those two frames in the lint; since #37803 does not touch the lint file, that would have gone red on main after the second merge with nothing forcing anyone to notice, so the overlap is now textual.

The five src/io/PipeReader.rs comments about a protector "pre-existing on the parent chain" describe the reader's own &mut self entry points (close, finish, start, watch, and the Windows on_read), which parents call directly; converting this chain does not change them.

Test

test/internal/source-lints/file-poll-dispatch-raw.test.ts locates every frame of the chain by name (Bun__internal_dispatch_ready_poll, on_kqueue_event, on_epoll_event, on_update, __bun_run_file_poll including its extern "Rust" declaration, on_dns_poll) and checks:

• signature: the poll arrives as *mut FilePoll (a self receiver on the FilePoll methods counts as by-reference unless it is a raw receiver), and no parameter takes it as &FilePoll / &mut FilePoll;
• hand-off: each frame calls the next frame(s) of the chain itself, with its pointer as the first argument (the entry point's pointer is its let x: *mut FilePoll binding). This is what keeps the chain closed: a helper interposed on any edge, whether it takes &mut FilePoll or is a &mut self method called as (*this).helper(), and a &mut *this argument (which coerces and would compile) are all reported;
• body: no let binding is a &[mut] FilePoll or a fn-long &mut *.. / unsafe { ..as_mut().. } reborrow.

Fixtures cover the main spellings of all six frames (19 findings), the converted spellings (none), and six mutations of the converted chain (interposed &mut FilePoll helper, interposed &mut self helper, &mut *this argument on the epoll edge, as_mut() binding, untyped entry binding, NonNull parameter), with the expected line numbers written out by hand. On main it reports 13 lines across the three files (the six frames above); on this branch it is clean, and it also fails on the intermediate state where only posix_event_loop.rs is converted. The kqueue function is #[cfg]'d to macOS/FreeBSD, so the lint is also what pins that path from the Linux lanes.

A behavioural fail-before test is not possible for the reason given above (the old code never touched the references after the owner ran).

Verification

• cargo check and cargo clippy for bun_io on x86_64-unknown-linux-gnu and aarch64-apple-darwin (the kqueue function, including the syslog! / debug_assert! spellings), cargo check on x86_64-unknown-freebsd; cargo clippy -p bun_runtime; cargo fmt --check; test/internal/source-lints/ as a directory (88 pass).
• Against the debug build of this diff: test/js/bun/spawn/spawn.test.ts, spawn-many-teardown.test.ts, spawn-pipe-stale-fd-unregister.test.ts (pipe EOF and process exit deinit the poll from inside the dispatch), test/js/node/dns/dns-tcp-bidirectional-poll.test.ts, dns-lookup-keepalive.test.ts, dns-resolver-concurrent-timeout.test.ts (re-registration and deinit of the c-ares poll from inside Channel::process, i.e. the on_dns_poll path), test/js/node/process/process-memory-pressure.test.ts; earlier revision of the same code also ran spawn-streaming-stdin.test.ts, spawn-stdin-destroy.test.ts and the shell suites pipeline_stack, epipe, shell-blocking-pipe, shell-pipe-read-fault, shell-write-fault. test/js/node/child_process/ passes except for the $SHELL test (the env bun bd runs tests with has no SHELL) and the 20-debug-child GC test hitting its 5 s budget on this machine (its fixture prints OK when run directly); spawn-pipe-leak.test.ts (750 debug children per test) hits its 30 s budget here the same way. io: return a FilePoll to its store through the owner's pointer, not a &mut receiver #37803 reports the same local failures.

[robobun]

^{Updated 12:05 PM PT - Aug 12th, 2026}

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

• test/bake/deinitialization.test.ts - pid 5652 segmentation fault at address 0x0 on 🪟 2019 x64

---

🧪   To try this PR locally:

bunx bun-pr 37837

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

bun-37837 --bun

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 8 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: ae77cfbe-24f0-46f7-94e3-855e00451fa4

📥 Commits

Reviewing files that changed from the base of the PR and between 9a543cc and bcb51e0.

📒 Files selected for processing (8)

• src/runtime/api/JSBundler.rs
• src/runtime/bake/DevServer.rs
• src/runtime/bake/bake_body.rs
• src/runtime/bake/mod.rs
• src/runtime/bake/production.rs
• test/bake/app-plugins-release.test.ts
• test/bake/fixtures/app-plugins-release/app-plugins-release.ts
• test/bake/fixtures/app-plugins-release/server.ts

---

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

[robobun]

Status: fix pushed, waiting on CI.

Reproduced on 1.4.0-canary with the fixture in this PR (test/bake/fixtures/app-plugins-release/app-plugins-release.ts): each of the three paths leaves heapStats().objectTypeCounts.BundlerPlugin === 1 after the dev server is gone and a full GC has run; with this branch all three report 0, and the rest of each report (cell count while serving, dev server deinit count, error message) is unchanged.

[claude]

I reviewed this PR and didn't find any bugs. Because it reworks GC-root ownership (protect/unprotect balance via a new RAII type) and reorders the MaybeUninit<DevServer> field-write sequence in init, a human look would still be worthwhile.

What was reviewed:

• OwnedPlugin Drop pairs Plugin::create's protect with Plugin::destroy's tombstone+unprotect; DerefMut goes through opaque_mut.
• DevServer::init reorder: bundler_options stays in the local options across the fallible FileSystem::init/Watcher::init/init_transpiler calls, so an early Err drops it (releasing the cell) instead of leaking it in the never-assume_init'd box; nothing else reads (*p).bundler_options in that window.
• on_plugins_resolved's debug_assert!(plugin.is_none()) matches ensure_route_is_bundled, which only takes the ask-server path when the slot is None, so a Borrowed never overwrites an Owned.
• From<bake_body::SplitBundlerOptions> moves the OwnedPlugin (no double-destroy from the removed Drop for UserOptions).

Extended reasoning...

Overview

The PR fixes a leak of the JSBundlerPlugin JSC cell held by Bun.serve({ app: { plugins } }) dev servers. It introduces OwnedPlugin (RAII wrapper whose Drop calls Plugin::destroy, i.e. tombstone + unprotect()) in JSBundler.rs, changes bake_body::SplitBundlerOptions.plugin from Option<NonNull<Plugin>> to Option<OwnedPlugin>, adds bake::DevServerPlugin { Owned, Borrowed } for the dev-server slot (which can also hold a pointer to the server's ServePlugins cell it must not free), and reorders the w!(bundler_options, ...) write in DevServer::init to after the fallible watcher/transpiler steps so an early Err drops the local (and its OwnedPlugin) instead of stranding it in the never-assume_init()'d box. The manual Drop for UserOptions is removed. Three new leak-regression tests cover stopped-server, setup-throws, and init-fails.

Security risks

None in the traditional sense; the risk here is memory safety — a mispaired protect/unprotect is either a leak or a UAF. The change moves toward RAII, which is the right direction. Plugin::destroy tombstones before unprotecting, so late JS-side deliveries are swallowed (matching every other caller). The Borrowed arm carries a raw NonNull<Plugin> owned by ServePlugins, which the same server releases; the dev server is dropped by the server, so the borrow does not dangle.

Level of scrutiny

High. This is native memory-management code intersecting JSC GC roots and a hand-rolled MaybeUninit<DevServer> per-field init. The reorder is subtle: it relies on the documented property that pre-assume_init() writes into the box are never dropped on Err, so ownership must stay in the local until after the last fallible step that reads it. I verified nothing reads (*p).bundler_options between the old and new write positions (only &options.bundler_options is read), and that options — with framework already partially moved out — still drops bundler_options on the earlier FileSystem::init/Watcher::init error paths.

Other factors

The tests are well-constructed (per-process fixture, heapStats().objectTypeCounts.BundlerPlugin after bounded GC polling, cross-checked against getDevServerDeinitCount() and error messages so each path is proven taken). The PR description explicitly demonstrates USE_SYSTEM_BUN=1 failing on all three cases. The debug_assert! in on_plugins_resolved is justified by ensure_route_is_bundled at DevServer.rs:1976 only reaching the ask-server path when plugin.is_none(). The OwnedPlugin type is intentionally identical to #37805's for a clean merge. Given the subtlety of the MaybeUninit interaction and the new Owned/Borrowed ownership split, this warrants a maintainer review even though no defects were found.