Repository navigation
Flaky: javascript-subprocess-tree cap-0 case, the debuggee exits 0xC0000005 once under the pre-push integration run (Windows) #1119
Description
One failure in a pre-push integration run on Windows, 2026-11-10, on feat/1025-stdio-2026 (PR #1116). The same push passed on an immediate retry with no change, and the test file passed 3 of 3 when run alone.
Test: tests/adapters/javascript/integration/javascript-subprocess-tree.test.ts › "with the child-session cap at 0 the program is still adopted and its fork is released by a throwaway attach"
What failed: the launch answer was stopped, but the debuggee's exit code was -1073741819 (0xC0000005, an access violation) where the test expects 0:
AssertionError: {"success":true,"state":"stopped","message":"Debugging started for …/tests/fixtures/javascript/subprocess-tree/parent.js. Current state: stopped. The program exited with code -1073741819 without hitting any breakpoint.","data":{"warning":"1 breakpoint(s) never bound during this run: child.js:14 (Unbound breakpoint). …
So it is the debugged Node process (the parent, or the fork whose code it relays) that died natively, not the server or the adapter. With DEBUG_MCP_MAX_CHILD_SESSIONS=0 the fork is released by a throwaway attach-then-detach (#501's lever, src/proxy/throwaway-release.ts), so the crash window is plausibly js-debug attaching to and detaching from a Node process that is still starting, under the load of the parallel integration run.
Environment: Windows 11, Node v24.14.1, js-debug v1.140.0, the pre-push hook's unit + integration run (integration: 35 files in parallel).
Not established: which process crashed (parent or fork); whether it reproduces on Linux or on a newer Node (24.14.1 also carries nodejs/node#56645, a libuv abort at exit on Windows fixed in 24.20.0 — a different failure, but the same Node build); how often it happens. One occurrence in three hook runs today.
Suggested first step: rerun the case in a loop under load with DAP_TRACE=1 and capture the fork's exit code separately from the parent's, to see whether the crash is in the released fork and whether it lines up with the throwaway detach.
Activity
debugmcpdev commentedon Nov 11, 2026
A possibly related sighting with the same exit code, from a
/testdebuggersweep on the same Windows box (2026-11-11, Node v24.14.1, build offix/1025-closeout@8d21f7a2). Second-hand: the sweep's lead reproduced it three times; I have not re-run it.examples/javascript/idle_server_attach_target.jswith no breakpoint set. The pending pause lands when a request arrives, atTCP.emitInitNative(<node_internals>/internal/async_hooks:193), with a correct no-program-frame note.get_local_variablesanswersvariables: [], "The Local: emitInitNative scope is empty."terminatedand node has exited with -1073741819 (0xC0000005); stderr carries no crash text.If this is the same crash, it is a path that reaches it on demand rather than once under load: a paused Node 24.14.1 process dying right after scopes/variables are read at an internal frame. That would point at Node or js-debug rather than at the cap-0 release path this issue suspects. Worth trying first when someone picks this up, and worth re-running on a newer Node 24.
The companion finding from the same sweep, where a breakpoint is set, is #1146.