module: compile cache leaks temporary files when persistence fails
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 74/100
- Issue 類型
- 缺陷
- 描述清晰度
- 描述清楚
- 活躍度
- 活躍
- 技術堆疊
- cpp, javascript, nodejs
- 領域
- backend, performance, testing
研究方向
從 src/compile_cache.cc 第 478-516 行附近開始，執行提供的 RLIMIT_FSIZE 重現，以追蹤臨時檔案處理在 write、close 和 rename 失敗時的行為。在支援的 POSIX 平台上新增回歸測試，驗證持久化失敗不會留下帶有隨機後綴的臨時檔案。完成標準是：失敗的快取寫入會關閉描述元、移除臨時路徑，並維持快取失敗時的正常處理。
由索引模型根據 Issue 內容生成。
描述
Version
v24.15.0
Platform
Linux pike 7.0.0-29-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 17 20:52:35 UTC 2026 x86_64 GNU/Linux
Subsystem
module compile cache
What steps will reproduce the bug?
This uses RLIMIT_FSIZE=0 to make mkstemp() succeed and the subsequent write fail. It requires no third-party dependencies or elevated privileges.
tmp="$(mktemp -d)"
mkdir -p "$tmp/cache"
printf '%s\n' 'module.exports = 42;' >"$tmp/fixture.cjs"
(
cd "$tmp"
ulimit -f 0
trap '' XFSZ
NODE_COMPILE_CACHE="$tmp/cache" node -e "require('./fixture.cjs')"
)
find "$tmp/cache" -type f -printf '%P %s bytes\n'
Example output:
v24.15.0-x64-cf738c9d-1000/712488c2.LuhsmB 0 bytes
v24.15.0-x64-cf738c9d-1000/8e9c99c2.hwlSas 0 bytes
v24.15.0-x64-cf738c9d-1000/9fb526e9.wPP9zO 0 bytes
The Node process exits with status 0.
How often does it reproduce? Is there a required condition?
Every run on the Linux system above. The required condition is that creation of the temporary cache file succeeds but a later write, close, or rename fails. EDQUOT, ENOSPC, and EFBIG are representative failure modes.
What is the expected behavior? Why is that the expected behavior?
The compile cache should continue to fail gracefully, but it should close the temporary file descriptor and unlink the temporary file whenever persistence does not complete. A failed cache write is disposable internal state and should not consume additional filesystem space or inodes.
What do you see instead?
Each failed entry leaves its random-suffix temporary file in the compile-cache directory. On the write-error path, its file descriptor also remains open until process teardown.
In a real EDQUOT incident, one Node process left 3,424 zero-byte compile-cache temporary files in one minute. This amplified a block-quota failure into substantial inode consumption.
Additional information
Current main creates the temporary file, then immediately continues on write, close, or rename errors without unlinking it:
The same control flow is present in v24.15.0.
A possible fix is an RAII cleanup guard established immediately after successful uv_fs_mkstemp() that:
- closes the descriptor if it is still open;
- unlinks the temporary path unless the rename succeeded;
- is disarmed only after successful rename;
- preserves the original persistence error.
A regression test can use the same RLIMIT_FSIZE technique on supported POSIX platforms and assert that no random-suffix temporary files remain.
- 主要語言
- JavaScript
- 星號
- 122k
- 分支
- 37.4k
- 平均合併
- 4 天 11 小時
- 30 天內合併 PR
- 294
環境準備
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
nodejs/node 的其他 Issue
-
doc
難度 2/5 1-3 小時 新手友好度 65/100
維護者通常 1 天內回覆
-
build
難度 1/5 1 小時以內 新手友好度 88/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 84/100
nodejs/node#65994 · 2 則留言 · 2 個 reaction ·
維護者通常 1 天內回覆
-
難度 1/5 1 小時以內 新手友好度 90/100
維護者通常 1 天內回覆
-
feature request
難度 2/5 1-3 小時 新手友好度 68/100
維護者通常 1 天內回覆
相似的 Issue
-
agent/quality hive/hosted-available-lke648397-260827-5n31 quality testing
難度 1/5 1 小時以內 新手友好度 90/100
維護者通常 1 天內回覆
-
難度 2/5 半天 新手友好度 78/100
jaegertracing/jaeger-ui#4512 ·
維護者通常 1 天內回覆
-
feedback simulation workshop
難度 2/5 1-3 小時 新手友好度 84/100
githubnext/gh-aw-workshop#3857 ·
維護者通常 2 天內回覆
-
area-clientside-dartpad
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 1 天內回覆
-
難度 1/5 1 小時以內 新手友好度 72/100
quarkusio/extensions#3432 ·
維護者通常 1 天內回覆