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
cpptools process: 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.
Summary
Starting with 1.33.x, the
cpptoolsprocess 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
cpptoolsprocess is not terminated. It gets reparented tosystemd --userand keeps its entire allocation resident indefinitely — one such orphan was observed holding 7.1 GB.Environment
.vsix(cpptools-linux-x64.vsix)Measurements
Same machine, same workspace, identical sampling method (
/proc/<pid>/statusVmRSS +/proc/<pid>/statutime+stime, every 10s):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)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: 4096had no effect — the process passed 6 GB and continued growing.Orphaned process on VS Code exit
After VS Code exits,
cpptoolssurvives with its parent changed tosystemd --user: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 legitimatelysystemd, 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
cpptoolsprocess:awk '/^VmRSS/{print $2}' /proc/<pid>/statusNotes and limitations
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.