Blob/ArrayBuffer memory not reclaimed by GC after dereferencing

[ReD-GuardiaN]

What version of Bun is running?

1.3.11

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What steps can reproduce the bug?

1. Fetch multiple URLs and store the resulting Blobs in an array
2. Clear the array (blobs = []) to remove all references
3. Call Bun.gc(true) multiple times, wait 8+ seconds
4. Observe that RSS memory is not released

Single-file repro that works with both Bun and Node:

// Run: bun repro.js | node --expose-gc repro.js

const FETCH_COUNT = 50;
const isBun = !!globalThis.Bun;
const runtime = isBun ? `Bun ${Bun.version}` : `Node ${process.version}`;

let blobs = [];

const startRss = process.memoryUsage().rss / 1024 / 1024;
console.log(`${runtime} | Start memory: ${startRss.toFixed(1)}mb`);

for (let i = 0; i < FETCH_COUNT; i++) {
  const res = await fetch("https://www.w3schools.com/html/mov_bbb.mp4");
  blobs.push(await res.blob());
  if ((i + 1) % 10 === 0) {
    const rss = process.memoryUsage().rss / 1024 / 1024;
    console.log(`fetched ${i + 1}/${FETCH_COUNT}, memory: ${rss.toFixed(1)}mb`);
  }
}

const peakRss = process.memoryUsage().rss / 1024 / 1024;
console.log(`\nPeak memory: ${peakRss.toFixed(1)}mb (${blobs.length} blobs)`);

blobs = [];
if (isBun) Bun.gc(true);
if (global.gc) global.gc();
await new Promise((r) => setTimeout(r, 3000));
if (isBun) Bun.gc(true);
if (global.gc) global.gc();
await new Promise((r) => setTimeout(r, 5000));
if (isBun) Bun.gc(true);
if (global.gc) global.gc();

const finalRss = process.memoryUsage().rss / 1024 / 1024;
const released = peakRss - finalRss;
const pct = ((released / (peakRss - startRss)) * 100).toFixed(1);

console.log(`\nAfter GC: ${finalRss.toFixed(1)}mb`);
console.log(`Released: ${released.toFixed(1)}mb (${pct}%)`);
console.log(parseFloat(pct) > 70 ? "\n✅ GC working" : "\n❌ Memory leak — GC did not free blobs");

What is the expected behavior?

Memory should be reclaimed after all Blob references are removed and Bun.gc(true) is called. Node.js correctly frees ~73% of allocated memory in the same scenario.

What do you see instead?

Bun releases 0% of memory. Full comparison on the same machine:

	Bun 1.3.11	Node v25.6.0
Start	105.1 MB	56.9 MB
Peak	184.2 MB	125.3 MB
After GC	184.3 MB	75.3 MB
Released	-0.2 MB (0%)	50.0 MB (73%)

Additional information

Related issues:

• Memory Leak with Blob/ArrayBuffer and Bun's Garbage Collection #12941 — I originally reported this on Bun 1.1.21. It was closed as "won't fix" by @Jarred-Sumner who used a modified repro wrapping blobs in a function scope. However, explicitly clearing references (blobs = []) + forced GC should work identically to scope exit — that's basic GC behavior. The bug persists on 1.3.11.

• Bun memory leak with simple fetch polling script #28427 — Same underlying issue (fetch memory leak), opened recently, also on 1.3.11. The automated bot (robobun) marked it as "unable to reproduce" but used a local HTTP server instead of real remote fetches, which doesn't trigger the same code path for Blob/body buffering.

This is a clean, minimal repro with no cache: "force-cache", no frameworks, no extra dependencies — just fetch → blob() → dereference → GC. The issue is in how Bun's runtime handles Blob/ArrayBuffer backing stores during garbage collection.

[robobun]

✅ Fix submitted in PR #28743.

Root cause: scheduled_response_buffer is written on the HTTP thread, allocating its backing memory on the HTTP thread's mimalloc heap. When GC later frees the Blob on the main JS thread, mi_free() puts the block on the HTTP thread's delayed-free list. Since the HTTP thread is idle after fetches complete, those pages are never returned to the OS.

Fix: Clone the buffer to the main thread's heap when transferring body data in onBodyReceived/toBodyValue. The body data then lives on the main thread's heap and is properly reclaimable by GC.

CI status: All Linux/Alpine/Ubuntu builds and tests pass. The 4 darwin test failures are pre-existing (same failures on recently merged PR #28733) and unrelated to this change.

• bun bd test regression/issue/28741 passes (28.5% released)
• USE_SYSTEM_BUN=1 bun test regression/issue/28741 fails (0% released)

[github-actions]

Found 3 possible duplicate issues:

1. Blob allocations cause excessive memory, and GC does not release all memory / Windows 10 / Blob,Uint8Array,ArrayBuffer #20544
2. Memory leak when downloading file (both @google-cloud/storage and Bun's S3) #20487
3. Doing a large amount of fetch requests results in a memory leak #20912

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[ReD-GuardiaN]

This is not a duplicate. The referenced issues (#20544, #20487, #20912) are different problems.

This issue has already resulted in a fix PR (#28743) that identifies the root cause: scheduled_response_buffer is allocated on the HTTP thread's mimalloc heap, and when GC frees the Blob on the main JS thread, the memory is never returned to the OS because the HTTP thread is idle.

Please do not auto-close.

[ReD-GuardiaN]

Linux (Docker) results confirm the leak

Tested in Docker containers (Bun 1.3.11 vs Node v25.8.2) with detailed memory breakdown (heapUsed, external, arrayBuffers):

Bun 1.3.11 (Linux):

Start: rss=31.0mb heap=0.2mb ext=0.0mb ab=0.0mb
Peak:  rss=84.9mb heap=40.1mb ext=39.9mb ab=0.0mb
After GC: rss=85.1mb heap=37.9mb ext=37.7mb ab=0.0mb
Released: heap=2.2mb ext=2.2mb ab=0.0mb

Node v25.8.2 (Linux):

Start: rss=41.4mb heap=3.7mb ext=1.4mb ab=0.0mb
Peak:  rss=136.7mb heap=8.4mb ext=6.6mb ab=40.7mb
After GC: rss=136.8mb heap=7.8mb ext=3.6mb ab=0.1mb
Released: heap=0.6mb ext=3.0mb ab=40.6mb

	Bun 1.3.11	Node v25.8.2
Blob storage	external (39.9mb)	arrayBuffers (40.7mb)
After GC	37.7mb external (5% freed)	0.1mb arrayBuffers (99.7% freed)

Key observations:

• Bun stores blob data as external memory and reports arrayBuffers as 0 — it doesn't track them properly
• Node correctly tracks blob data under arrayBuffers and frees 99.7% of it after GC
• RSS doesn't drop on Linux for either runtime (normal OS behavior — pages stay mapped), but the underlying allocations are freed in Node and retained in Bun
• Confirms the root cause: blob data lives on the HTTP thread's mimalloc heap and can't be reclaimed by main-thread GC

[robobun]

@ReD-GuardiaN The CI failures are pre-existing macOS test flakes — the same 4 darwin tests fail with the same exit codes on the most recently merged PR (#28733). All Linux/Alpine/Ubuntu builds and tests pass on this PR.

The fix itself is a small change in FetchTasklet.zig: when transferring the response buffer from the HTTP thread to the body value on the main thread, the data is now cloned into a fresh main-thread allocation instead of just moving the pointer. This way, when GC later frees the Blob, mimalloc can properly return those pages to the OS.

[ReD-GuardiaN]

The leak is wider than just fetch — comprehensive API test

I tested multiple Bun APIs for the same memory leak pattern (allocate 50x 1MB buffers → clear references → GC → measure). Results show 8 out of 12 APIs leak in Bun, while Node releases ~99% in all cases.

Bun 1.3.11 vs Node v25.6.0 (Windows x64):

API	Bun released	Node released	Status
fetch → blob	69.7%	76.6%	OK
fetch → arrayBuffer	0.7%	99.4%	LEAK
fetch → text	-0.0%	91.3%	LEAK
Bun.file → arrayBuffer	-15.8%	—	LEAK
Bun.file → text	42.0%	—	LEAK
Bun.file → bytes	204.4%	—	OK
Bun.spawn stdout	90.3%	97.6%	OK
gunzipSync	37.3%	100.7%	LEAK
localhost fetch → blob	33.7%	—	LEAK
localhost fetch → arrayBuf	93.2%	—	OK
Local new Blob()	27.1%	99.8%	LEAK
Local ArrayBuffer	0.2%	92.0%	LEAK

Key findings:

• Bun.file() leaks too — same pattern as fetch. PR Clone fetch response buffer to main thread heap for proper GC reclamation #28743 only fixes FetchTasklet.zig, not file I/O
• gunzipSync leaks — this is a synchronous call, so the cross-thread mimalloc explanation doesn't fully cover it
• localhost fetch leaks blobs — contradicts the robobun bot's "unable to reproduce" on Bun memory leak with simple fetch polling script #28427 (they tested localhost but didn't check memory release)
• Even Local Blob() and Local ArrayBuffer show leaks in sequential testing, suggesting accumulated pressure on Bun's GC

This points to a systemic issue with how Bun's GC tracks and releases native/external memory, not just a fetch-specific mimalloc cross-thread problem.

Repro script: https://gist.github.com/ReD-GuardiaN/df884176daef29535839085fbb477ee4 — single file, works with both bun test-other-apis.js and node --expose-gc test-other-apis.js.