How to further diagnose a Lanugage Server Crash

[BartVandewoestyne]

When using a certain large workspace (lots of files and also 78 git submodules of which some third party code), my VSCode becomes unworkable after a while. I see memory going up until 100% and sometimes also CPU load going very high, until my Linux desktop freezes and is not workable anymore. After some time, it becomes better again and I see a "Language Server Crash" in the Ouptput for the C/C++ or cpptools extension.

As this makes my VSCode and computer unworkable, I would like to further diagnose this problem and get to the root cause of it. Where should I start to further investigate this? Are there any log files I can collect? I already tried attaching the gdb debugger to the cpptools process following the instructions at https://github.com/microsoft/vscode-cpptools/wiki/Attaching-debugger-to-cpptools-or-cpptools%E2%80%90srv but that somehow didn't work: as soon as the memory starts going up, my computer becomes unworkable and I cannot press "pause" to see the call stacks. If I let it run until the language server crashes, typing 'bt' in the Debug Console also doesn't give my any callstack.

Advice on how to further diagnose is welcome!

Version info:

C/C++ extension:
1.21.6

VSCode:
Version: 1.92.2
Commit: fee1edb8d6d72a0ddff41e5f71a671c23ed924b9
Date: 2024-08-14T17:29:30.058Z
Electron: 30.1.2
ElectronBuildId: 9870757
Chromium: 124.0.6367.243
Node.js: 20.14.0
V8: 12.4.254.20-electron.0
OS: Linux x64 5.15.0-119-generic

[bobbrow]

To get a quick answer about whether this is caused by the large volume of files or perhaps a symlink, add this setting to your .vscode/settings.json file and then reload the VS Code window.

    "C_Cpp.files.exclude": {
        "**/*": true,
    }

If the answer is yes, then it's possible we have an issue with how we're indexing your workspace.

Do note that with the setting configured this way, some features like Go To Definition, Outline, and Find all References will not have a full picture of your project and may not provide accurate results.

[BartVandewoestyne]

Before you posted this answer, In a desparate attempt to not hang my computer each time, I had already removed a build-alike directory inside the workspace that contained quite some volume of files (IIRC some 5 to 6 GB on .o and other files... don't know exactly what was in there). After the removal of that directory, I no longer experienced the memory going up and computer becoming unusable. So it must definitely have had something to do with that directory. Not sure what though.

I now don't have that directory anymore, but should I regenerate it, I'll see if the problem occurs again and if it does, I will get back to this. Suppose I can recreate the problem. What could be a next step to further diagnose?

[bobbrow]

If your build directory is in the workspace, VS Code (and the C++ extension) will listen for file events in that folder and index its contents. If that folder is all binaries and intermediate files, you will want to exclude it. I recommend using the files.exclude setting (instead of C_Cpp.files.exclude) so that both the VS Code editor and the C++ extension ignore that folder.

[bobbrow]

It would look something like this:

"files.exclude": {
    "**/build": true  // <-- or whatever the name of your build folder is
}