NODE_PENDING_PIPE_INSTANCES causes 0xC0000005 crash on Windows when a named-pipe listen() loses a bind race (EADDRINUSE)
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 3/5
- 預估耗時
- 1-2 天
- 新手友好度
- 68/100
- Issue 類型
- 缺陷
- 描述清晰度
- 描述清楚
- 活躍度
- 冷清
- 技術堆疊
- javascript, node.js
研究方向
從 src/win/pipe.c 開始，特別查看 uv_pipe_pending_instances()、uv_pipe_bind2() 和 uv__pipe_close()，然後檢查 lib/net.js，了解待處理執行個體的設定方式。在設定 NODE_PENDING_PIPE_INSTANCES 的情況下於 Windows 上執行 repro.js；當競爭失敗的 named-pipe listen 發出 EADDRINUSE 且程序繼續執行時，即表示完成。
由索引模型根據 Issue 內容生成。
描述
Version
Reproduces on v22.19.0, v22.23.2, v24.11.1, v24.19.0, v26.7.0 (latest of each supported line as of 2026-08-05). Does not reproduce on v20.19.2.
Platform
Windows 11 x64 (also observed on windows-latest GitHub Actions runners).
Subsystem
net / libuv (Windows named pipes)
What steps will reproduce the bug?
Set NODE_PENDING_PIPE_INSTANCES, then try to listen() on a named pipe whose name is already taken. The EADDRINUSE error is delivered normally, but the process then dies with an access violation (exit code 0xC0000005 / 3221225477, -1073741819) while closing the failed server handle — no JS stack, no assertion message.
// repro.js — crashes with 0xC0000005 on Node 22/24/26; prints "survived" without the env var (or on Node 20)
process.env.NODE_PENDING_PIPE_INSTANCES = '32';
const net = require('net');
const PIPE = '\\\\.\\pipe\\pw-repro-' + process.pid;
const a = net.createServer(() => {});
a.listen(PIPE, () => {
const b = net.createServer(() => {});
b.on('error', err => {
console.log('bind failed as expected:', err.code); // EADDRINUSE
setTimeout(() => { console.log('survived'); a.close(); }, 500);
});
b.listen(PIPE); // loses the bind — node then closes the failed handle → crash
});
> node repro.js
bind failed as expected: EADDRINUSE
(process dies with 0xC0000005)
Result matrix:
| node | NODE_PENDING_PIPE_INSTANCES=32 |
unset |
|---|---|---|
| v20.19.2 | survives | survives |
| v22.19.0 / v22.23.2 | crash | survives |
| v24.11.1 / v24.19.0 | crash | survives |
| v26.7.0 | crash | survives |
What is the expected behavior?
The losing listen() emits EADDRINUSE and the process continues. Racing binds on a well-known pipe name is a standard singleton-election pattern on Windows (first bind wins via FILE_FLAG_FIRST_PIPE_INSTANCE), so losing the race is an expected, recoverable condition.
What do you see instead?
The process dies with 0xC0000005 (access violation) with no further output, after the error event has been delivered.
Additional information — root cause in libuv (src/win/pipe.c)
When the env var is set, node's lib/net.js (createServerHandle) calls handle.setPendingInstances() → uv_pipe_pending_instances(), which sets the UV_HANDLE_PIPESERVER flag immediately — before any bind, while handle->pipe.serv.accept_reqs is still NULL:
void uv_pipe_pending_instances(uv_pipe_t* handle, int count) {
if (handle->flags & UV_HANDLE_BOUND)
return;
handle->pipe.serv.pending_instances = count;
handle->flags |= UV_HANDLE_PIPESERVER; /* <-- set before bind */
}
uv_pipe_bind2() allocates accept_reqs, but on failure (here: ERROR_ACCESS_DENIED from CreateNamedPipeW with FILE_FLAG_FIRST_PIPE_INSTANCE → mapped to UV_EADDRINUSE) its error path frees accept_reqs and resets it to NULL — without clearing UV_HANDLE_PIPESERVER.
Node then closes the handle; uv__pipe_close() trusts the flag and walks the accept requests:
if (handle->flags & UV_HANDLE_PIPESERVER) {
for (i = 0; i < handle->pipe.serv.pending_instances; i++) {
pipeHandle = handle->pipe.serv.accept_reqs[i].pipeHandle; /* accept_reqs == NULL → AV */
...
(Debug builds die earlier, on assert(handle->pipe.serv.accept_reqs) in uv__pipe_endgame().)
Without the env var, uv_pipe_pending_instances() is never called, the flag is only set by a successful bind, and the crash path is unreachable — matching the observed gating.
How we hit this
Playwright set NODE_PENDING_PIPE_INSTANCES=32 to work around slow accept-replenishment on busy named-pipe servers (default 4 pending instances). Any child process that inherited the env and lost a deliberate singleton bind race then crashed the daemon with 0xC0000005 on all Windows CI jobs (microsoft/playwright#42128).
- 主要語言
- JavaScript
- 星號
- 122k
- 分支
- 37.4k
- 平均合併
- 4 天 11 小時
- 30 天內合併 PR
- 294
環境準備
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
nodejs/node 的其他 Issue
-
test
難度 2/5 1-3 小時 新手友好度 68/100
維護者通常 1 天內回覆
-
doc
難度 1/5 1 小時以內 新手友好度 90/100
維護者通常 1 天內回覆
-
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 天內回覆
相似的 Issue
-
Complexity: Small P-Feature: Projects page ready for merge team role: back end/devOps role: front end size: 0.25pt
難度 1/5 1-3 小時 新手友好度 88/100
維護者通常 1 天內回覆
-
難度 1/5 1 小時以內 新手友好度 67/100
bellingcat/toolkit#905 ·
-
self-care self-care:docs-build-time-investigator
難度 2/5 半天 新手友好度 76/100
githubnext/gh-aw-cao#14191 ·
維護者通常 1 天內回覆
-
effort:low impact:medium RAG status: auto-triaged
難度 2/5 1-3 小時 新手友好度 84/100
mastra-ai/mastra#25229 · 2 則留言 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 88/100
sugarlabs/musicblocks#8984 ·
維護者通常 1 天內回覆