Render process crash due to OOM when using CommitMono font

[wrs]

Type: Bug

Doing a build (cmd-shift-B) crashes the window pretty consistently. I've restarted the computer with no improvement. If I go back to an earlier version of VS Code (1.95.3) it no longer happens. This is also happening with recent versions of Cursor, but Cursor 0.44.11 based on VS Code 1.93.1 doesn't crash.

Main output:
2025-02-03 14:38:58.027 [error] CodeWindow: renderer process gone (reason: crashed, code: 5)
2025-02-03 14:38:58.328 [info] Extension host with pid 55544 exited with code: 0, signal: unknown.
2025-02-03 14:42:10.500 [error] CodeWindow: renderer process gone (reason: crashed, code: 5)
2025-02-03 14:42:10.782 [info] Extension host with pid 55946 exited with code: 0, signal: unknown.

VS Code version: Code 1.96.4 (cd4ee3b, 2025-01-16T00:16:19.038Z)
OS version: Darwin arm64 24.1.0
Modes:

System Info

Item	Value
CPUs	Apple M4 Max (16 x 2400)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off
Load (avg)	3, 2, 3
Memory (System)	64.00GB (10.46GB free)
Process Argv	--disable-extensions --crash-reporter-directory /tmp/code .
Screen Reader	no
VM	0%

Extensions disabled

A/B Experiments

vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805:30301674
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
vscaac:30438847
c4g48928:30535728
azure-dev_surveyone:30548225
2i9eh265:30646982
962ge761:30959799
9b8hh234:30694863
pythonnoceb:30805159
pythonmypyd1:30879173
h48ei257:31000450
pythontbext0:30879054
cppperfnew:31000557
dwnewjupyter:31046869
nativerepl2:31139839
pythonrstrctxt:31112756
nativeloc2:31192216
iacca1:31171482
5fd0e150:31155592
dwcopilot:31170013
stablechunks:31184530
6074i472:31201624
dwoutputs:31217127
9064b325:31222308
copilot_t_ci:31222730

[wrs]

Here are three crashdumps

BTW, the build is just a vanilla cargo build. But the crash also happens under other circumstances — seems like just using the terminal will cause it after a bit, or starting a debug session.

{
            "label": "Cargo Build (dev)",
            "type": "process",
            "command": "cargo",
            "args": [
                "build"
            ],
            "options": {
                "env": {
                    "DEFMT_LOG": "trace"
                }
            },
            "problemMatcher": [
                "$rustc"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }

[wrs]

Still happening in latest release — see dump in #241119

[deepak1556]

Can you try the following,

• Run Developer: Toggle Developer Tools
• Now switch to the Memory tab in the DevTools
• Check the following option Allocations on timeline with allocation stack traces enabled

• Start the profile
• Go back to the application and perform the steps that eventually lead to the crash
• Stop the profile after a while if possible before the crash
• Attach the generated profile to this issue

[wrs]

The snapshot doesn't finish after the crash, it just tries for a minute or two and stops with a "DevTools disconnected from the page" error. I'm attaching a profile after the terminal is open and has some output in it, but not enough output to trigger the crash. (All it takes is a command with 50-60 lines of output.)

Heap-20250219T220751.heaptimeline.zip

[wrs]

Hi @deepak1556, wondering if there's anything else you need, or if you know of any workarounds to try.

[deepak1556]

Sorry for the delay here, I was trying to get a custom build that would help capture snapshots when the crash happens but facing some issues to get that working.

I looked at the provided timeline but it is not enough to pinpoint the issue since live object count is too small to indicate a leak.

The snapshot doesn't finish after the crash, it just tries for a minute or two and stops with a "DevTools disconnected from the page" error

Yeah this is a limitation with the devtools. The heap limit for the renderer process is set to 4GB, when old space allocations reaches this limit is when you see the OOM crash from V8. Can you monitor the memory usage of the renderer from activity monitor and stop the timeline capture when it reaches around 1~2 GB this should provide enough data on any leaks.

[wrs]

Great, I'm happy to run a custom build. At this point I'd even be willing to learn how to build VSCode locally if it gets this fixed!

Data points:

• Once the freeze occurs, the renderer process gets to >7.5GB before it crashes.
• The freeze seems related specifically to adding multiple lines to the terminal quickly. I can run VI and scroll around indefinitely. I can just hit return in the shell and scroll single lines indefinitely. But if I cat a 5-line file twice, the freeze happens as soon as I scroll two lines off the top of the pane.
• The freeze happens when there is only 500-600MB in the render process, not 1-2GB.

I made several profiles in an attempt to get as close as possible to the freeze, plus one showing the no-freeze case of single lines in the shell. GitHub uploads seem to be broken today (?) so here is a Dropbox link: https://www.dropbox.com/scl/fi/f2x3olgku6k2nqxe5eeaj/profiles.zip?rlkey=8ezrzel81r6mg68ev41lzwi1k&dl=0