Alright, let's add another entry to the ever-growing tome of "tools that promise developer nirvana and instead deliver a slow, silent death by a thousand memory leaks." I'm running VSCode on Ubuntu 22.04, because apparently I still enjoy having some semblance of control over my own machine, and I've been trying to give this "OpenClaw" suite a fair shake for C/C++ work. The premise was appealing: an open-source, integrated set of tools for analysis and navigation. Fool me once.
The setup works, deceptively, for about half an hour. IntelliSense is peppy, go-to-definition works, all the bells and whistles. Then, precisely as if a cron job fires, the language server just… gives up. The `C/C++` tag in the status bar goes from a cheerful green check to a spinning wheel, then to an error icon. Hovering over a variable yields "Loading…" forever. The only fix is to kill the `cpptools` process or restart VSCode entirely, which of course nukes my entire context.
Here's the usual suspect list, because we must always perform the ritual of checking our own yard before blaming the new dog:
* VSCode: 1.89.1
* OS: Ubuntu 22.04.4 LTS (kernel 6.8.0)
* Key Plugins:
* ms-vscode.cpptools (v1.18.5)
* openclaw.openclaw-cpp (v0.3.1)
* ms-vscode.cmake-tools (v1.15.33)
* twxs.cmake (v0.0.17)
* eamodio.gitlens (v14.0.1)
I've already done the dance of disabling all other extensions. The conflict seems to be between `ms-vscode.cpptools` and `openclaw.openclaw-cpp`. With OpenClaw disabled, the Microsoft toolchain chugs along indefinitely (or at least until its own famously hungry memory consumption forces a restart). With OpenClaw enabled, the failure is predictable and time-based, not load-based. It happens even on a simple, single-file "Hello World" project.
The OpenClaw plugin seems to be injecting or interacting with the language server in some way that eventually exhausts a resource or deadlocks it. I've scoured the output channels (`C/C++`, `OpenClaw`, `Language Server`). No crash logs, no helpful errors—just silence, which is the most infuriating log message of all. The system monitor tells a subtle story: memory usage of the `cpptools` process climbs steadily but not astronomically, then plateaus right before IntelliSense dies. CPU goes to zero.
My `c_cpp_properties.json` is vanilla, pointing at the default system include paths. No fancy custom configurations. This feels like a classic plugin turf war over the Language Server Protocol pipe or some internal cache that gets corrupted and never cleared.
Has anyone else been masochistic enough to run this particular combination to ground? I'm looking for the specific poison, not just "disable one of them." I want to understand *why* two tools designed for the same language can't share a sandbox without one eventually smothering the other with a pillow. Is there a known hook or API conflict? Or is this just another case of plugin authors assuming they have sole ownership of the development environment?
-- cynical ops
Your k8s cluster is 40% idle.
Oh man, that 30-minute death spiral is a classic, and you've nailed the description. I've been down that exact road with `cpptools` on Linux, and it's almost always a resource exhaustion problem - it just fails to tell you.
The fact that it's timing out so predictably makes me think it's hitting a memory limit or a file handle cap. Before you go killing processes, try this next time it hangs: open the VSCode command palette (Ctrl+Shift+P) and run "C/C++: Log Diagnostics." That'll dump the language server logs. Then run "C/C++: Reset IntelliSense Database." It's less nuclear than a full restart and sometimes clears the blockage.
Also, check if OpenClaw is doing something in the background that adds more files to the workspace. Every time a new batch of headers gets discovered, the IntelliSense DB tries to re-index, and if it's already on the edge, that's the push over the cliff. You might need to set a `C_Cpp.maxCachedProcesses` limit in your settings.json to keep it in check.
What does your system monitor say about memory when it dies? I'd bet you see `cpptools` creeping up until it hits a wall.
— francesc
> The fact that it's timing out so predictably makes me think it's hitting a memory limit or a file handle cap.
That's the easy guess. I've seen it be a slow memory leak, but also a deadlock. Logs don't always show the wall, just the last gasp.
Resetting the database is just a slower restart. It doesn't fix the leak.
Check your systemd user session limits, not just the process. `loginctl user-settings` can hide a low TasksMax. The language server spawns kids. Hit that limit, it stalls, then times out. Looks like memory. Isn't.
Don't panic, have a rollback plan.