Version
v24.18.0
Platform
Microsoft Windows 11 Pro 10.0.26200, x64. LongPathsEnabled = 1.
Subsystem
module (compile cache)
What steps will reproduce the bug?
Run this PowerShell script. It calls module.enableCompileCache() on directories of different lengths under %TEMP%, and kills any call that has not returned after 6 seconds.
$base = Join-Path $env:TEMP 'cc-repro'
New-Item -ItemType Directory -Force -Path $base | Out-Null
foreach ($len in 200, 220, 230, 240, 245, 250, 260, 300) {
$p = $base; $i = 0
while ($p.Length -lt $len) { $p = Join-Path $p ("d" + ($i++)) }
$p = $p.Substring(0, $len).TrimEnd('\')
$psi = [System.Diagnostics.ProcessStartInfo]::new('node.exe')
$psi.Arguments = "-e `"const r=require('module').enableCompileCache(process.argv[1]);console.log(r.status+' '+(r.message||''))`" `"$p`""
$psi.UseShellExecute = $false; $psi.RedirectStandardOutput = $true
$proc = [System.Diagnostics.Process]::Start($psi)
if (-not $proc.WaitForExit(6000)) { $proc.Kill(); "{0} chars: HANG" -f $p.Length }
else { "{0} chars: {1}" -f $p.Length, $proc.StandardOutput.ReadToEnd().Trim() }
}
How often does it reproduce? Is there a required condition?
It happens every time for directory lengths 240 and 245, with %TEMP% under C:\Users\<user>\AppData\Local\Temp. The exact lengths that hang depend on the path's structure. In our case a real 283-character cache path also hung, while the synthetic 282-character path above fails cleanly.
What is the expected behavior? Why is that the expected behavior?
enableCompileCache() should return. It should either enable the cache or report failure, as it does for every other length:
200 chars: 1
220 chars: 1
230 chars: 0 Cannot create cache directory: no such file or directory
234 chars: 0 Cannot create cache directory: no such file or directory
240 chars: HANG
245 chars: HANG
250 chars: 0 Cannot create cache directory: no such file or directory
260 chars: 0 Cannot create cache directory: no such file or directory
300 chars: 0 Cannot create cache directory: no such file or directory
What do you see instead?
The call never returns. The main thread spins inside native code:
- One core runs at 100%.
- Process I/O counters show about 150,000 file-system metadata operations a second (
OtherOperationCount), with no writes.
- Timers never fire, and the inspector cannot pause the thread, so neither
--cpu-prof nor Debugger.pause produces a stack.
- A
--prof tick profile attributes about 99% of ticks to ntdll.dll under the calling script.
The same hang occurs when the cache is enabled through the NODE_COMPILE_CACHE environment variable. In a worker thread, that variable also freezes a main thread that is waiting on the worker.
Additional information
We hit this in production: an application enabled the compile cache in its launcher, its entry module and its worker threads, using a cache path built from a long build ID. A maintenance command then spun for 25 minutes before it was killed.
Workaround: NODE_DISABLE_COMPILE_CACHE=1.
fs.mkdirSync(path, { recursive: true }) succeeds for all of these lengths on the same machine, so the problem appears specific to the compile-cache directory creation path. It may be an MKDirp retry loop on ENOENT for paths near MAX_PATH without the \\?\ prefix.
Version
v24.18.0
Platform
Microsoft Windows 11 Pro 10.0.26200, x64.
LongPathsEnabled= 1.Subsystem
module (compile cache)
What steps will reproduce the bug?
Run this PowerShell script. It calls
module.enableCompileCache()on directories of different lengths under%TEMP%, and kills any call that has not returned after 6 seconds.How often does it reproduce? Is there a required condition?
It happens every time for directory lengths 240 and 245, with
%TEMP%underC:\Users\<user>\AppData\Local\Temp. The exact lengths that hang depend on the path's structure. In our case a real 283-character cache path also hung, while the synthetic 282-character path above fails cleanly.What is the expected behavior? Why is that the expected behavior?
enableCompileCache()should return. It should either enable the cache or report failure, as it does for every other length:What do you see instead?
The call never returns. The main thread spins inside native code:
OtherOperationCount), with no writes.--cpu-profnorDebugger.pauseproduces a stack.--proftick profile attributes about 99% of ticks tontdll.dllunder the calling script.The same hang occurs when the cache is enabled through the
NODE_COMPILE_CACHEenvironment variable. In a worker thread, that variable also freezes a main thread that is waiting on the worker.Additional information
We hit this in production: an application enabled the compile cache in its launcher, its entry module and its worker threads, using a cache path built from a long build ID. A maintenance command then spun for 25 minutes before it was killed.
Workaround:
NODE_DISABLE_COMPILE_CACHE=1.fs.mkdirSync(path, { recursive: true })succeeds for all of these lengths on the same machine, so the problem appears specific to the compile-cache directory creation path. It may be anMKDirpretry loop on ENOENT for paths nearMAX_PATHwithout the\\?\prefix.