Antigravity language server OOM crash - missing size guard on file-watcher read path

Google Antigravity
1

Environment: Antigravity IDE 2.5.5 (also reproduced on 2.1.1), Windows 11 25H2, language_server_windows_x64.exe

Summary

Watching a workspace that contains a large, actively-growing file (in my case, one that crossed 1.4 GB while receiving frequent appends) causes language_server_windows_x64.exe to blow past the system commit limit and crash the session. This isn’t a slow leak. It’s a single oversized allocation, repeated on every file-change event, with no upper bound.

Root cause

The server writes its own Go crash log on OOM (crash_11516_*.log, attached). It names the exact call site:

runtime.mallocgc(0x5b6ef6f7, 0, 0)          # 1,533,998,839 B = 1.428 GiB, one allocation
runtime.slicebytetostring
go_utils.BytesToUTF8NoBom                     encoding.go:77
fs.Path.ReadFileAsUTF8NoBom                   path.go:139
implicit.(*workspaceEventRouter).UpdateFile   workspace_event_router.go:93
WorkspaceInfoManager.sendFileUpdateToListeners workspace_file_listener.go:565
WorkspaceInfoManager.DidChangeWatchedFiles     workspace_file_listener.go:489
lsp.(*LspClient).DidChangeWatchedFiles.func1   lsp.go:169

The allocation size (0x5B6EF6F7 = 1,533,998,839 bytes) matches the changed file’s size on disk, byte for byte. DidChangeWatchedFiles reads the entire changed file into memory as a UTF-8 string on every watch event, and slicebytetostring allocates a second, same-sized buffer for the conversion — roughly 2x the file’s size per read. Since the file was being appended to continuously, the event fired repeatedly. The recovered crash log (2,286 lines, 103 goroutines total) shows the read path stacking up: 16 goroutines in DidChangeWatchedFiles, 13 in workspaceEventRouter.UpdateFile, 11 in ReadFileAsUTF8NoBom, and 7 actively mid-allocation on the 1.43 GiB read at the moment of the crash. 13 concurrent reads, each approximately 2.857 GiB, total 37.14 GiB; adding in-flight allocations and heap overhead aligns with the measured 41.93 GiB against a 41.23 GiB commit limit.

Repro

  1. Open a workspace in Antigravity.
  2. Have a process continuously append to a file inside that workspace. Once it crosses roughly 1 GB, the effect is reproducible (mine triggered around 1.4 GB).
  3. Observe the commit climbing in Task Manager. On my machine (15.23 GiB RAM, 41.23 GiB commit limit) it reached 41.93 GiB, and the session crashed.

Suggested fix

Add a size check before the full-file UTF-8 read in DidChangeWatchedFiles / ReadFileAsUTF8NoBom, and either skip, stream, or debounce reads for files above a threshold. A default max-watched-file-size setting (overridable) would also help, since large data files probably shouldn’t be fully re-read on every write regardless of this specific bug.

Workaround (for anyone else hitting this)

Excluding large/bulk-data extensions and directories in files.watcherExclude stops the read from firing. I verified this against every file over 200 MB in my workspace, before and after the exclusion change, using VS Code’s actual glob-matching semantics rather than assuming coverage.

2