Repository navigation
Unbounded memory growth (~183 MB/min) with one core at 100% in 1.33.x; 1.32.2 unaffected #14689
Description
Summary
Starting with 1.33.x, the cpptools process grows unboundedly at ~183 MB/min while pinning one CPU core at a constant 100%. Downgrading to 1.32.2 on the same machine and workspace eliminates the problem entirely (memory converges at ~300 MB). The growth is in anonymous mmap regions, not the browse database.
A second, related defect: when VS Code exits, the cpptools process is not terminated. It gets reparented to systemd --user and keeps its entire allocation resident indefinitely — one such orphan was observed holding 7.1 GB.
Environment
- cpptools: 1.33.7 and 1.33.8 affected; 1.32.2 not affected
- VS Code: 1.109.5 (x64)
- OS: Ubuntu 20.04.5 LTS, kernel 5.15.0-58-generic
- CPU / RAM: Intel i7-12700 (20 cores) / 31 GiB
- Installed from the GitHub release
.vsix(cpptools-linux-x64.vsix)
Measurements
Same machine, same workspace, identical sampling method (/proc/<pid>/status VmRSS + /proc/<pid>/stat utime+stime, every 10s):
| Metric | 1.33.7 | 1.32.2 |
|---|---|---|
| RSS range | 5063 → 6128 MB | 209 → 295 MB |
| Growth rate | +183 MB/min | +13 MB/min (converges) |
| CPU (one core) | constant 100%, range 100–100% | avg 34%, range 25–60% |
| Threads | 58 | 32 |
| After ~48 min uptime | (not reached; 4782 MB at 11 min) | 297 MB, 16% CPU |
1.33.7 grew monotonically for the entire 350 s sample with no plateau. CPU accumulated exactly 1000 ticks per 10 s interval throughout — zero variance.
1.32.2 rose to 288 MB during initial indexing, then oscillated between 298–306 MB for the remaining 380 s. The final sample (301 MB) is lower than an intermediate one (305 MB), i.e. memory is being reused normally. The +13 MB/min figure is entirely attributable to the startup indexing phase; post-indexing growth is zero.
Extended observation confirms this holds. After 2870 s (~48 min) of continuous use, 1.32.2 sat at 297 MB / 31 threads / 16% CPU — below its own 303 MB peak from the initial sample, with 272 MB anonymous mmap. For comparison, 1.33.7 had already reached 4782 MB at 103% CPU after only 644 s.
Memory composition (1.33.7, from /proc/<pid>/smaps)
4707 MB anonymous mmap (no file backing)
67 MB [heap]
The workspace's browse database is only 7.9 MB, so the allocation is unrelated to index data. Thread count was constant at 58, ruling out thread leakage.
C_Cpp.maxMemory: 4096 had no effect — the process passed 6 GB and continued growing.
Orphaned process on VS Code exit
After VS Code exits, cpptools survives with its parent changed to systemd --user:
pid=1959176 ppid=5062 (systemd --user) rss=4474 MB
Observed behaviour of one orphan over 290 s: RSS climbed 3738 → 4474 MB at 100% CPU for the first 160 s, then froze completely (RSS constant, CPU ~0) for the remaining 130 s while holding the full allocation. It responds normally to SIGTERM, so signal handling is intact — it simply never receives a shutdown instruction once its IPC peer is gone.
Another orphan was later reaped at 7100 MB.
Note for anyone writing cleanup tooling: cpptools-srv's parent is legitimately systemd, and it associates with its main process via its first command-line argument (cpptools-srv <main-pid> {GUID}) rather than the process tree. Parent-based orphan detection will produce false positives on it.
Reproduction
- Open a C/C++ workspace with cpptools 1.33.7 or 1.33.8
- Sample the
cpptoolsprocess:awk '/^VmRSS/{print $2}' /proc/<pid>/status - Observe monotonic growth at ~183 MB/min with one core at a constant 100%
- Downgrade to 1.32.2 and repeat — memory converges at ~300 MB
Notes and limitations
- Workspace activity levels across the two samples were not strictly controlled. However, the ~14× difference in growth rate far exceeds what load variation could explain, and the qualitative difference is decisive: 1.32.2's curve converges while 1.33.7's rises monotonically with zero CPU variance.
- The specific trigger (which file, project layout, or operation initiates the runaway allocation) has not been isolated.
- 1.33.0–1.33.6 were never run on this machine, so the regression cannot be narrowed further than "introduced somewhere in 1.33.x". Confirmed: 1.32.2 good, 1.33.7 and 1.33.8 affected.
- Local version history was recovered from
CPP.<version>.*keys in~/.config/Code/User/globalStorage/state.vscdb, which cpptools writes per version actually run: 1.30.3 → 1.30.4 → 1.30.5 → 1.31.3 → 1.31.4 → 1.31.5 → 1.32.2 → 1.33.7 → 1.33.8.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
sean-mcmanus commentedon Aug 18, 2026
viewshell (@haigithub) Are you able to provide any more repro info or a call stack etc.? See https://github.com/microsoft/vscode-cpptools/wiki/Attaching-debugger-to-cpptools-or-cpptools%E2%80%90srv and https://github.com/microsoft/vscode-cpptools/wiki/Troubleshooting-Performance-Issues .
karlp commentedon Aug 18, 2026
I'm seeing this too, I get about 8-10 minutes before 32G is exhausted and OOM killer kicks in killing vscode. I'm on vscode 1.133 and 131. (I'd tried downgrading to 1.131 to fix it, before discovering it was this extension instead) Running on fedora 42, x86_64
sean-mcmanus commentedon Aug 18, 2026
Karl Palsson (@karlp) Yes, I think we need more repro info. i.e. does it repro with a simple project? If so, what is special about certain projects that is triggering it? The logging that is occurring while the memory is increasing could also help (with C_Cpp.loggingLevel set to the hidden value of "7", or the previously mentioned call stack or performance logs could help too).
And/or what actions are required to trigger it? Does it repro when no files are ever open (but the C/C++ extension is still activated by something like a .vscode/c_cpp_properties.json in the workspace or a C/C++ command being run)?
karlp commentedon Aug 18, 2026
I have a ~ordinary esp-idf project, project itself is only ~15 files of my work. I open vscode, build and flash (because I'm trying to work) and it starts. It may start earlier, but I'm trying to work.
14 remaining items
keithrausch commentedon Aug 27, 2026
I'm also getting <10 minutes of up time before my system freezes from OOM (and closing VS Code leaves the extension dangling). I get the desire to fix this properly in the next version of the extension, but why not push out an immediate revert instead?
sean-mcmanus commentedon Aug 27, 2026
Georgios Vasilakis (@Vge0rge) With 1.34.0...I assume so if you're seeing the cpptools termination fix. It sounds like you're hitting a different OOM spike issue -- can you get a call stack or perf log stack somehow, https://github.com/microsoft/vscode-cpptools/wiki/Attaching-debugger-to-cpptools-or-cpptools%E2%80%90srv, https://github.com/microsoft/vscode-cpptools/wiki/Troubleshooting-Performance-Issues, or more repro info?
keithrausch 1.33.8 or 1.34.0? We're not reverting because it only seems to repro in certain rarish cases and downgrading to 1.32.2 is a workaround. And we want to get a fix as soon as we can get enough info for what this other issue is.
ReedW2012 commentedon Aug 28, 2026
reproduced this on 1.33.2, 1.33.8 and 1.34.0. My last working database was with 1.32.2, on the same source code: the Matter SDK, project-chip/connectedhomeip at v1.4.0.0. It contains 174 self-referential directory symlinks.
My workaround, without pinning 1.32.2, is an explicit browse.path in c_cpp_properties.json that omits the directory containing the cycles.
sean-mcmanus commentedon Aug 28, 2026
ReedW2012 Thanks -- looking into that now for 1.34.2.
sean-mcmanus commentedon Aug 29, 2026
ReedW2012 We should have a fix in our 1.34.2 release targeting Monday. Our assumption is that this is the same root issue that others have reported. It was a different root cause from the fix that went into 1.34.0.
Vge0rge commentedon Aug 31, 2026
Hey, I didn't have the time to do debugging yet unfortunately. But I guess now I will wait for 3.4.2. If that doesn't fix it I will provide more call stack as suggested here.
RussKie commentedon Sep 1, 2026
3 different devboxes - all behaving the same with v1.33.8 -> the extension chewing all memory and constantly hogging CPU - making devboxes almost unusable and eventually OOM'ing
sean-mcmanus commentedon Sep 1, 2026
Georgios Vasilakis (@Vge0rge) Igor Velikorossov (@RussKie) ReedW2012 https://github.com/microsoft/vscode-cpptools/releases/tag/v1.34.2 fixed a repro with self-referential directory symlinks. Let us know if anyone still hits this with 1.34.2 (be sure to reload window after installing it or it won't use the new version).
Vge0rge commentedon Sep 2, 2026
Sean McManus (@sean-mcmanus) I can confirm that 1.34.2 fixes the issue for me and it works as expected 👍 Thanks for your effort!
ReedW2012 commentedon Sep 2, 2026
I can also confirm that 1.34.2 fixes the issue for me. Thanks for the quick fix, Sean McManus (@sean-mcmanus) !