microsoft / microsoft/vscode

Code Helper (Renderer) sustains >200% CPU and grows to 12 GB with thousands of IOSurface regions on macOS

Open
#329,118 3 comments 0 reactions 1 assignee Claimed by @anthonykim1 View on GitHub
freeze-slow-crash-leak macos terminal
Dominant language
TypeScript
Stars
193k
Forks
42.4k
PR merge metrics
PR metrics pending

Description

Does this issue occur when all extensions are disabled?: Not tested yet

- VS Code Version: 1.131.0 (Universal/arm64), commit e4c7e7b1d6d060162f4aa7f8225271b67ce1df75
- Electron: 42.7.0
- OS Version: macOS 27.0 (26A5388g), Apple Silicon (M5), 16 GB RAM
- Remote OS: Linux x64 over Remote - SSH

## Summary

A single VS Code window renderer (`Code Helper (Renderer)`) intermittently enters a sustained high-CPU state and rapidly accumulates memory and graphical resources. The affected window is a Remote - SSH workspace. Other VS Code windows remain idle and small, and the extension host remains near idle.

During one observation period, the affected renderer used 109–222% CPU and its physical footprint grew from approximately 9.4 GB to 11.6 GB, later reaching a 12.3 GB peak. The VS Code GPU process concurrently used approximately 15–25% CPU, but its stack was dominated by Metal command submission and appears to be downstream of the renderer workload.

## Steps to Reproduce

The exact trigger is not known yet, but the problem has reproduced in the same workspace/window:

1. Open a Linux workspace using Remote - SSH.
2. Keep the window open with two small untitled editors (one Markdown document, about 54 KB) and normal workbench UI.
3. Continue using VS Code or leave the window open.
4. After some time, observe the window process in `code --status` or Process Explorer.

## Actual Behavior

The affected renderer enters a sustained high-CPU state and its footprint/resource counts grow continuously.

Representative measurements from the same renderer:

```text
CPU: 109–222%
Physical footprint: 9.4 GB -> 11.6 GB
Physical footprint (peak): 12.3 GB
Swapped writable regions: approximately 8 GB
IOSurface regions: approximately 10,000 -> 11,435
IOSurface virtual size: approximately 156 MB -> 179 MB
App-Specific Tag 16 regions: approximately 91,545 -> 101,141
Mach ports: approximately 255–265 (stable)
Threads: approximately 19–21
```

A second newly opened VS Code renderer, measured at the same time, stayed at approximately 45 MB physical footprint and 0% CPU.

`code --status` mapped the affected process to the Remote - SSH window. The related processes were approximately:

```text
window renderer: 109–222% CPU
GPU process: 15–25% CPU
extension host: 1–4% CPU
Remote SSH helper: approximately 0.1% CPU
```

The untitled Markdown backup was only 54,419 bytes, 965 lines, with a longest line of 787 bytes, so this does not appear to be a large-file case.

A 10-second macOS `sample` of the renderer showed the main thread continuously executing V8 microtasks, object/property enumeration, serialization/deserialization, allocation, and GC-related paths. A simultaneous GPU-process sample showed repeated Metal command-buffer, texture copy, and render command submission.

The system experienced severe memory pressure while this happened (16 GB system RAM, about 8 GB of this renderer's writable regions swapped). Closing/reloading the affected window releases the resources.

## Expected Behavior

An idle or normally used Remote - SSH window should not continuously consume multiple CPU cores or grow to 10+ GB physical footprint and thousands of IOSurface regions.

## Additional Context

- The VS Code binaries and processes are native arm64, not running through Rosetta.
- GPU acceleration was enabled with ANGLE Metal and Skia Graphite.
- The affected window had restored workbench state for the built-in Chat panel and extension-contributed sidebars, but no specific extension has been proven to trigger the leak.
- The local extension host was mostly idle, suggesting the CPU time is in the window renderer rather than extension-host computation.
- The current process had only about 265 Mach ports, so this does not look like port-space exhaustion.
- I can provide the macOS `sample` reports for both the renderer and GPU process if useful.

## Diagnostics Available

- 10-second `sample` report of `Code Helper (Renderer)` captured during the high-CPU state
- 8-second `sample` report of the VS Code GPU process captured at the same time
- `vmmap -summary` snapshots showing footprint, swap, App-Specific Tag regions, and IOSurface growth
- `code --status` process-to-window mapping

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.