nodejs / nodejs/node

NODE_PENDING_PIPE_INSTANCES causes 0xC0000005 crash on Windows when a named-pipe listen() loses a bind race (EADDRINUSE)

Ouverte
#65,057 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Langage dominant
JavaScript
Étoiles
122k
Forks
37.3k
Merge moyen
4 j 2 h
PR mergées (30 j)
283

Description

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).

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez par src/win/pipe.c, en particulier uv_pipe_pending_instances(), uv_pipe_bind2() et uv__pipe_close(), puis examinez lib/net.js pour voir comment les instances en attente sont configurées. Exécutez repro.js sous Windows avec NODE_PENDING_PIPE_INSTANCES défini ; c’est terminé lorsque l’écoute du named pipe perdant émet EADDRINUSE et que le processus survit.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
javascript, node.js
Domaine
backend, networking, operating-systems
Type d'issue
Bug
Difficulté
3/5
Temps estimé
1-2 jours
Activité
Calme
Clarté
Clairement spécifiée
Accessibilité débutants
68/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.