Summary
A VS Code Insiders extension host crashed with a native V8 OOM while attaching/debugging from a large workspace. Symbolication points to JSON.stringify() of the breakpoint predictor cache as the final allocation.
Possibly related to #2173, but this dump identifies a specific allocation and call site.
Environment
- VS Code Insiders:
1.137.0-insider (1f625adb84abf41cdff31f40f66e58a222f033f6)
- Electron:
42.10.0
- macOS arm64
- Process: local extension host (
node.mojom.NodeService)
- Process uptime: 5,853 seconds
Symbolicated crashing thread
partition_alloc::internal::OnNoMemoryInternal
partition_alloc::TerminateBecauseOutOfMemory
(anonymous namespace)::V8OOMErrorCallback
v8::internal::V8::FatalProcessOutOfMemory
v8::internal::HeapAllocator::AllocateRawSlowPath
v8::internal::Factory::NewStringFromTwoByte
v8::internal::JsonStringify
<JavaScript frames>
node::fs::FSReqPromise<...>::Resolve
node::fs::AfterMkdirp
The NewStringFromTwoByte length argument was 0x55b8eb, or 5,617,899 characters.
The same workspace's ms-vscode.js-debug/bp-predict.json is 5,617,904 bytes, effectively matching the failed allocation. Its top-level key describes the default workspace scan rooted at <workspace>/out/**/*.js.
This matches BreakpointPredictorCachedState.store():
await fs.mkdir(path.dirname(this.path), { recursive: true });
await fs.writeFile(this.path, JSON.stringify(value));V8 OOM annotations
heap.limit 4,294,967,296
heap.used 3,585,540,660 (83.5%)
heap.total 3,747,840,000
heap.total_available 552,433,816
old_space.size 2,636,120,064
old_space.used 2,506,918,964 (95.1%)
external_memory 95,189,642
location CALL_AND_RETRY_LAST
The extension host had already grown close to the old-space limit while processing the workspace. Serializing the roughly 5.6 MB cache required one additional complete two-byte V8 string and became the fatal allocation.
Additional context
- Only one matching crash dump was present in the 24-hour window, so I cannot compare signatures across multiple dumps.
- The extension-host trace contained heavy activity immediately before the crash, including large bursts of
setContext/_setContext, but the failed allocation size and native stack point directly to breakpoint-cache serialization.
- I have not attached the dump or full logs because they contain local paths. I can provide the dump privately if useful.
Could you determine the appropriate fix in js-debug? The underlying memory growth may be broader than the final cache serialization.
Summary
A VS Code Insiders extension host crashed with a native V8 OOM while attaching/debugging from a large workspace. Symbolication points to
JSON.stringify()of the breakpoint predictor cache as the final allocation.Possibly related to #2173, but this dump identifies a specific allocation and call site.
Environment
1.137.0-insider(1f625adb84abf41cdff31f40f66e58a222f033f6)42.10.0node.mojom.NodeService)Symbolicated crashing thread
The
NewStringFromTwoBytelength argument was0x55b8eb, or 5,617,899 characters.The same workspace's
ms-vscode.js-debug/bp-predict.jsonis 5,617,904 bytes, effectively matching the failed allocation. Its top-level key describes the default workspace scan rooted at<workspace>/out/**/*.js.This matches
BreakpointPredictorCachedState.store():V8 OOM annotations
The extension host had already grown close to the old-space limit while processing the workspace. Serializing the roughly 5.6 MB cache required one additional complete two-byte V8 string and became the fatal allocation.
Additional context
setContext/_setContext, but the failed allocation size and native stack point directly to breakpoint-cache serialization.Could you determine the appropriate fix in js-debug? The underlying memory growth may be broader than the final cache serialization.