cpptools-srv too many zombie processes causing laptop to crash

[jacob-02]

Environment

• OS and version: Ubuntu 22.04
• VS Code: 1.93.0
• C/C++ extension: v1.22.2 (pre-release)
• OS and version of remote machine (if applicable):
• GDB / LLDB version: GNU gdb (Ubuntu 12.1-0ubuntu1~22.04.2) 12.1

Bug Summary and Steps to Reproduce

Bug Summary:
On performing any form of action like replacing all the words with another word using vscode multiple cpptools-srv processes are created with use close to 0.5 GB of RAM each causing the laptop to crash. The CPU utilisation also goes up.

Steps to reproduce:

1. Open any cpp project
2. With default config
3. Search and replace a word that is there across all files
4. Check the system monitor to see multiple processes

Debugger Configurations

{
	"version": "2.0.0",
	"tasks": [
		{
			"type": "cppbuild",
			"label": "C/C++: clang-14 build active file",
			"command": "/usr/bin/clang-14",
			"args": [
				"-fcolor-diagnostics",
				"-fansi-escape-codes",
				"-g",
				"${file}",
				"-o",
				"${fileDirname}/${fileBasenameNoExtension}"
			],
			"options": {
				"cwd": "${fileDirname}"
			},
			"problemMatcher": [
				"$gcc"
			],
			"group": "build",
			"detail": "compiler: /usr/bin/clang-14"
		}
	]
}

Debugger Logs

NIL

Other Extensions

No response

Additional Information

Before

After

[sean-mcmanus]

@jacob-02 500 MB of RAM usage by cpptools-srv is expected behavior. If your laptop is crashing due to that, it could be an issue with your operation system or hardware. How much memory does your machine have? Does the issue repro with 1.21.6?

[jacob-02]

@sean-mcmanus Firstly thank you for your response. When there is only one process of cpptools-srv running it's fine. But once I perform any action these zombie processes with each using 500 MB adding upto 2-3 GB of my RAM and the more actions I perform the more number of these processes get created. Also I have 16 GB of RAM. And I didn't get what you mean by 1.21.6? Is that a vscode version?
Thank you again

[sean-mcmanus]

@jacob-02 Why do you say they are "zombie" processes? Are they in a zombie state? When do they get into that state? It sounds like the zombie processes are causing too much RAM to be used? 1.21.6 is the non-prerelease version of the C/C++ extension.

[jacob-02]

@sean-mcmanus I assume them to be zombie processes since they don't die. I try to force kill them but even more processes get created on trying to do that. As I have shared screenshots before and reiterated in the previous comment, on performing an action using vscode for example doing a search and replace in a workspace. Yes the same issue is there while using 1.21.6. And yes the zombie processes are causing too much RAM to be used.
Thank you

[sean-mcmanus]

@jacob-02 We spawn a cpptools-srv process for every file that is opened. Can you confirm that if you have just one C/C++ file open and don't do a find all references (rename or call hierarchy, which also spawn more cpptools-srv) that only 1 cpptools-srv process is active? Do the cpptools-srv processes use CPU, such as if you paste in a bunch of code into a file? If so, then they're not zombie processes but active processes.

If you do a find/replace on many files, we will spawn a cpptools-srv process for every file that is opened.

You could try setting/lowering the C_Cpp.maxCachedProcesses, C_Cpp.maxMemory (and other related "max" settings) to try to use less resources.

Using 3 GB on a 16 GB machine isn't expected to crash a machine. Although, I do remember seeing this happen using our C/C++ extension a long time ago on an older Ubuntu running Raspberry Pi (it seemed to me like a bug with the OS or hardware).

[sean-mcmanus]

@jacob-02 But I seem to remember the C_Cpp.max* settings may not be applied if the cpptools-srv processes are all spawned in response to a bunch of file open requests at once (possibly "by design" although maybe we could do something extra to improve the situation). We have some previously opened similar issues like #9798 and #11014 .

[sean-mcmanus]

@jacob-02 When I do a find/replace, I don't get the editors activated and so I get no cpptools-srv processes started -- do you have some VS Code setting that keeps the editted/replaced documents open? Changing that setting could resolve the issue for you.

[jacob-02]

@sean-mcmanus If there is only one file open and I don't perform any actions then only one cpptools-srv is created. Also 3GB is only cpptools-srv. I have other applications open too for the task. Regarding a setting that keeps edited/replaced documents open, the files don't get opened when I perform find/replace but multiple cpptools-srv are created. Also sometimes 2 code processes also get started. I can try to reduce the C_Cpp.maxCachedProcesses, C_Cpp.maxMemory (and other related "max" settings) and see if that will reduce the problem.

[sean-mcmanus]

@jacob-02 I don't repro that. When I find/replace it doesn't create any extra cpptools-srv. I see clang-tidy get spawned if "C_Cpp.codeAnalysis.clangTidy.enabled": true, is used. Maybe you have a particular setting that changes the behavior? (I'm not aware of any setting that would change the behavior). Normally, we only spawn a cpptools-srv after we detect a new visible document.

My logging with C_Cpp.loggingLevel set to "Debug" shows the follow messages:

textDocument/didOpen
textDocument/didChange
textDocument/didSave
textDocument/didClose
cpptools/fileChanged
tag parsing file:
Intellisense update pending for:

and not the messages below which occur for cpptools-srv process creation:

cpptools/didChangeVisibleTextEditors
cpptools/didChangeActiveEditor
IntelliSense update scheduled and TU acquisition started for:
sending compilation args for

How does your logging differ?

Also, normally an OS/hardware should be able to handle 3 GB out of 16 GB of memory usage from processes without crashing even with other apps using memory.

[ChuckyBill]

Hi...
I don't know what the language server thinks it's doing, but it has one of the following:

• an extreme memory leak
• poorly written handling of recursive includes

I myself use include guards, but I'm not sure everything forever does. In any case, no other editor I've ever used (including other versions of editors based on Visual Studio in some way) have ever used up enough memory to make my computer lag unresponsively for 3 minutes until the server finally gives up the ghost. I have 64 GiB of RAM, dude. This is CLEARLY a bug that needs more attention, and it's been happening to me for months. I like Code, but, I can't use it if it freezes my mouse for several minutes at a time.

What are you guys doing with 50+ GiB of ram in an effing text editor? Look, if you can't figure it out in the first 2-3 GiB, give up on that include. If it isn't because of some recursion, then I have no clue what you're doing.

Kernel:

• Linux: 6.8.0-45-generic

Distribution:

• Ubuntu 22.04.5 LTS

Memory (aforementioned):
64.0 GiB

Graphics:
NVIDIA T1000/PCIe/SSE2/ NVIDIA Corporation, etc.

Disk Capacity:
2.0 TB

Processor:
13th Gen Intel Core i9 13900k x 32

Includes (just for fun):

#include <sys/time.h>
#include <sys/ioctl.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/select.h>
#include <sys/wait.h>
#include <Python.h>
#include <syslog.h>

#include <unistd.h>
#include <fcntl.h>
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
#include <string.h>
#include <errno.h>
#include <signal.h>
#include <spawn.h>
#include <time.h>

#include <linux/usb/ch9.h>
#include <linux/usb/g_uvc.h>
#include <linux/usb/video.h>
#include <linux/videodev2.h>
#include <linux/v4l2-subdev.h>