Closed
Description
Version
v17.8.0
Platform
Microsoft Windows NT 10.0.19042.0 x64
Subsystem
net
What steps will reproduce the bug?
Run node named-pipe.js having the following content:
const net = require('net')
const server = net.createServer()
const namedPipe = '\\\\.\\pipe\\node-test-' + Date.now()
server.listen(namedPipe, function () {
const clients = new Array(50).fill(0).map(function () {
return net.connect(namedPipe)
})
for (const client of clients) {
// Causes access violation
client.destroy()
}
console.log('ok')
server.unref()
})How often does it reproduce? Is there a required condition?
Always for me. You may need to increase the amount of named pipe clients (50 in the example) in order to reproduce.
What is the expected behavior?
$ node named-pipe.js & echo %errorlevel%
ok
0
What do you see instead?
$ node named-pipe.js & echo %errorlevel%
-1073741819
Additional information
Reproduced on 17.8.0, 17.4.0, 16.14.2, 14.14.0, 8.14.0.
Stack trace:
ntdll.dll!RtlCreateUnicodeString()
KernelBase.dll!WaitNamedPipeW()
node.exe!pipe_connect_thread_proc(void * parameter) Line 825
at c:\ws\deps\uv\src\win\pipe.c(825)
ntdll.dll!RtlpTpWorkCallback()
ntdll.dll!TppWorkerThread()
kernel32.dll!00007fff91137034()
ntdll.dll!RtlUserThreadStart()
It seems that handle->name is NULL here.