René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"module.enableCompileCache() never returns on Windows for some cache-directory lengths (spins at 100% CPU)","articleBody":"### Version\n\nv24.18.0\n\n### Platform\n\nMicrosoft Windows 11 Pro 10.0.26200, x64. `LongPathsEnabled` = 1.\n\n### Subsystem\n\nmodule (compile cache)\n\n### What steps will reproduce the bug?\n\nRun 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.\n\n```powershell\n$base = Join-Path $env:TEMP 'cc-repro'\nNew-Item -ItemType Directory -Force -Path $base | Out-Null\nforeach ($len in 200, 220, 230, 240, 245, 250, 260, 300) {\n    $p = $base; $i = 0\n    while ($p.Length -lt $len) { $p = Join-Path $p (\"d\" + ($i++)) }\n    $p = $p.Substring(0, $len).TrimEnd('\\')\n    $psi = [System.Diagnostics.ProcessStartInfo]::new('node.exe')\n    $psi.Arguments = \"-e `\"const r=require('module').enableCompileCache(process.argv[1]);console.log(r.status+' '+(r.message||''))`\" `\"$p`\"\"\n    $psi.UseShellExecute = $false; $psi.RedirectStandardOutput = $true\n    $proc = [System.Diagnostics.Process]::Start($psi)\n    if (-not $proc.WaitForExit(6000)) { $proc.Kill(); \"{0} chars: HANG\" -f $p.Length }\n    else { \"{0} chars: {1}\" -f $p.Length, $proc.StandardOutput.ReadToEnd().Trim() }\n}\n```\n\n### How often does it reproduce? Is there a required condition?\n\nIt happens every time for directory lengths 240 and 245, with `%TEMP%` under `C:\\Users\\\u003cuser>\\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.\n\n### What is the expected behavior? Why is that the expected behavior?\n\n`enableCompileCache()` should return. It should either enable the cache or report failure, as it does for every other length:\n\n```\n200 chars: 1\n220 chars: 1\n230 chars: 0 Cannot create cache directory: no such file or directory\n234 chars: 0 Cannot create cache directory: no such file or directory\n240 chars: HANG\n245 chars: HANG\n250 chars: 0 Cannot create cache directory: no such file or directory\n260 chars: 0 Cannot create cache directory: no such file or directory\n300 chars: 0 Cannot create cache directory: no such file or directory\n```\n\n### What do you see instead?\n\nThe call never returns. The main thread spins inside native code:\n- One core runs at 100%.\n- Process I/O counters show about 150,000 file-system metadata operations a second (`OtherOperationCount`), with no writes.\n- Timers never fire, and the inspector cannot pause the thread, so neither `--cpu-prof` nor `Debugger.pause` produces a stack.\n- A `--prof` tick profile attributes about 99% of ticks to `ntdll.dll` under the calling script.\n\nThe 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.\n\n### Additional information\n\nWe 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.\n\nWorkaround: `NODE_DISABLE_COMPILE_CACHE=1`.\n\n`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.\n","author":{"url":"https://github.com/NickM83","@type":"Person","name":"NickM83"},"datePublished":"2026-10-01T15:40:22Z","url":"https://github.com/nodejs/node/issues/66438"}