nodejs / nodejs/node

`generatedSourceMapCache` is an unbounded strong Map: eval'd code with unique `//# sourceURL` grows the heap without limit under `--enable-source-maps`

オープン
#65,760 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

主要言語
JavaScript
スター
122k
フォーク
37.3k
平均マージ
4日 2時間
マージ済み PR(30日)
283

説明

Version

v26.6.0

Platform
Linux DESKTOP-ID7SI66 6.18.33.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun 18 21:54:43 UTC 2026 x86_64 GNU/Linux
Subsystem

lib/internal/source_map/source_map_cache.js

What steps will reproduce the bug?
// leak.cjs
const fs = require('node:fs');
const os = require('node:os');
const path = require('node:path');

const dir = fs.mkdtempSync(path.join(os.tmpdir(), 'smcache-'));
fs.writeFileSync(path.join(dir, 'big.js.map'), JSON.stringify({
  version: 3, sources: ['a.ts'], sourcesContent: ['x'.repeat(400 * 1024)], names: [], mappings: 'AAAA',
}));

const retained = () => { global.gc(); global.gc(); return (process.memoryUsage().heapUsed / 1e6).toFixed(0); };

console.log(`0 evals -> ${retained()} MB`);
for (let i = 1; i <= 1200; i++) {
  // The eval'd source is ~90 bytes and the map is an external file, so V8's own
  // retention of eval'd sources is not a factor. Only the sourceURL varies.
  (0, eval)(`({f:_=>_()})\n//# sourceURL=file://${dir}/z.js?${i}\n//# sourceMappingURL=big.js.map`);
  if (i % 400 === 0) console.log(`${i} evals -> ${retained()} MB`);
}
fs.rmSync(dir, { recursive: true, force: true });

Run the above script twice:

  1. node --expose-gc leak.cjs
  2. node --expose-gc --enable-source-maps leak.cjs

(results below)

Nothing keeps a reference to the evaluated functions and heapUsed is sampled after two forced GCs. So it is retained in memory.

How often does it reproduce? Is there a required condition?

On every run.

The bug is trigger when using --enable-source-maps (or NODE_V8_COVERAGE) plus generated code whose //# sourceURL differs each time it is evaluated (which is often the case with Nextjs HMR).

This bug is also reproduced on v24.20.0 (LTS), v26.6.0 and v26.8.1.

What is the expected behavior? Why is that the expected behavior?

Retained memory stays flat because nothing references the evaluated code, so its source map should be collectable, or at least the cache should be bounded.

What do you see instead?
Number of Evals --enable-source-maps no flag
0 evals 5 MB 5 MB
400 evals 170 MB 5 MB
800 evals 334 MB 6 MB
1200 evals 499 MB 6 MB

~415 KB retained per eval (the whole parsed map) which never decreases. The growth is unbounded.

Additional information
Possible fix

maybeCacheSourceMap stores into a strong, never-evicted Map when isGeneratedSource is true:

https://github.com/nodejs/node/blob/d8ddf46d15e146584cce7c245c0c82d7e58d51a5/lib/internal/source_map/source_map_cache.js#L157-L195

Module sources are weakly keyed through SourceMapCacheMap and stay collectable. Generated sources are not. The comment assumes generated sources are few.

A possible fix would be to bound generatedSourceMapCache with a byte-budgeted LRU, or store the map URL and parse on demand instead of retaining the parsed payload eagerly.

Real-world impact

This is part of a 3.2 GB OOM in a next dev server (next 16.3.4, Turbopack, node 26.6.0).

React's RSC dev machinery calls eval once per stack frame to rebuild owner stacks, appending
//# sourceURL=about://React/<env>/<file>?<counter++> plus an inlined ~525 KB source-map data URL.

The counter makes every key unique. A heap snapshot showed 3866 entries retaining 1457 MB under
context:generatedSourceMapCache which is 480 KB of sourcesContent and 132 KB of mappings per entry.

A few fast edits to one source file killed the process. The same workload is fine on deno and bun,
which do not cache generated source maps.

I am filing the React/Next side separately; this report is only about the cache being unbounded.

For those coming here from a similar next dev issue, use next dev --disable-source-maps as a workaround.

run after first render after 12 edits per edit
next dev 605 MB 1672 MB +89 MB
next dev --disable-source-maps 508 MB 580 MB +6 MB
AI Disclosure

I have used Claude to understand the underlying problem and create parts of the repro. The repro is also verified by me (the human).

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

lib/internal/source_map/source_map_cache.js、特に maybeCacheSourceMap、generatedSourceMapCache、SourceMapCacheMap を確認してください。提供されている leak.cjs を --enable-source-maps ありとなしで実行し、生成された source map が繰り返されても、source map の動作を維持したまま、保持されるヒープが無制限に増加しなくなったことを検証してください。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
javascript, node.js
領域
devtools, performance
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
活発
明瞭さ
おおむね明確
初心者へのやさしさ
55/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。