IntelliSense is memory-hungry after update

[invexed]

Type: LanguageService

• OS and Version: Fedora 28
• VS Code Version: 1.32.3
• C/C++ Extension Version: 0.22.0

After updating to the most recent extension version, the IntelliSense process consumes 6GB+ of RAM (which renders my 8GB machine unusable). If this is intended behaviour, may I ask how I can disable whatever feature is consuming that much memory?

[bobbrow]

This is not intended behavior. If it's a problem related to the new IntelliSense caching feature, you can disable it by setting the C_Cpp.intelliSenseCacheSize setting to 0.

We didn't see this in our testing. Can you share any more information about your project and/or configuration?

[invexed]

Thanks for the quick reply. Setting C_Cpp.intelliSenseCacheSize to 0 has indeed stopped the problem. I tried this earlier today to no avail, but deleting my project's .vscode folder before starting VS Code seemed to do the trick. The memory usage for the IntelliSense process is sitting at a steady 1.5GB now.

I have no idea if this is relevant, but I have C_Cpp.default.intelliSenseMode set to clang-x64 and the process is called Microsoft.VSCode.CPP.IntelliSense.Msvc.linux. When the problem occurred, the memory gradually increased in increments of around 400MB up to a maximum of 6.2GB (this value varied slightly each time I relaunched VS Code).

The project is pretty simple and is configured with CMake. I'm unable to share it but I can try to build a minimal project that reproduces the problem and share that?

[michelleangela]

Sending a sample project that reproduces the problem will help. What are the sizes of the source files in the actual project? Does some have a lot of #include files?

[michelleangela]

Also, could you send us a copy of the memory usage output that you are seeing? Is the 6.2GB physical or virtual memory?

[invexed]

I'm having trouble reproducing the problem now. Unfortunately I'll have to come back to it in a few days as I'm rather tied up with work at the moment.

It was physical memory.

[michelleangela]

Thanks @invexed. We'd also like to know the sizes of the cached precompiled headers (PCH) that are created when IntelliSense caching is enabled. The default cache path is "~/.vscode/ipch/" and the PCH files will have extension ".ipch".

[svb688]

this is an issue for me as well. "Microsoft.VSCode.CPP.IntelliSense.Msvc.linux" is using 13.7 GB memory. I've tried adding "C_Cpp.intelliSenseCacheSize": 0, to settings.json and the memory usage still climbs that high.

fresh ubuntu 18.04 install

[sean-mcmanus]

@svb688 Do you have any more repro details, such as what project it repros for and after how many files are opened? Is 1 process using 13 GB or is that split over many processes? How many workspace folders are being used?

[svb688]

It's just one process, with just one workspace folder. Is there a way to turn off intellisense for a particular file or folder?

I have a rather large file that might be bogging it down, I can try disabling it if so (a hello world project does not consume much memory).

[sean-mcmanus]

@svb688 You can surround the code in
#ifndef __INTELLISENSE__ #endif

We found a bug with large files that can cause lots of CPU and memory usage -- hopefully we should have a fix soon.

[svb688]

yup, the large file was the issue. I'll wait for the patch.

[crupest]

I met this problem as well.
First, I didn't notice the high memory comsuption so the extension kept eating memory until runing out of my 8G memory and leading my system to crash.
Then I rebooted and reopened code. At the beginning, everything seemed to work well with code which I think might haved been intellisensed before. But when I tried to add new code and intellisense, the Microsoft.VSCode.CPP.IntelliSense.Msvc.linux began to cosume memory and reach about 1.2GB until I found the problem. Then I stopped typing, it stopped increasing memory and kept at 1.2GB.

I'm using archlinux.
I only opened a simple cpp file as following (can't be compiled):

#include <iostream>
#include <xcb/xcb.h>

using std::cout;
using std::endl;

int main()
{
    xcb_connection_t* connection = xcb_connect(NULL, NULL);
    cout << "xcb connection established!" << endl;

    const xcb_setup_t* setup = xcb_get_setup(connection);
    cout << "get setup" << endl;

    xcb_format_iterator_t format_iter = xcb_setup_pixmap_formats_iterator(setup);
    cout << "pixel format count: " << xcb_set
    while (format_iter.rem)
    {
        xcb_format_next(&format_iter);
        cout << "pixel format " << format_iter.index << endl;
        cout << "  depth: " << format_iter.data->depth << endl;
        cout << "  bits_per_pixel: " << format_iter.data->bits_per_pixel << endl;
    }
    cout << endl;

    xcb_screen_iterator_t iter = xcb_setup_roots_iterator(setup);
}

I firstly think it might be related to xcb header files because one of the internal file xproto.h is of 12000+ lines.

I'm willing to provide any other info. Thx.

Update

Set C_Cpp.intelliSenseCacheSize to 0 solved the problem for me.
It seems even setting C_Cpp.intelliSenseCacheSize to 0 does not work after a while.

[satyajitghana]

Same problem here, i'm on arch linux (faced the same issue while on WSL Ubuntu), it eats away more than half of my memory, ipch files are 400mb each, and 4-5 of them, here is my settings for the extension, i think could be because of the boost library i'm using.

    "C_Cpp.intelliSenseCacheSize": 0,
    "C_Cpp.default.cppStandard": "c++14",
    "C_Cpp.default.cStandard": "c99",
    "C_Cpp.default.intelliSenseMode": "gcc-x64"

#include <boost/multiprecision/cpp_int.hpp>
#include <boost/math/constants/constants.hpp>
#include <boost/multiprecision/cpp_dec_float.hpp>
#include <boost/algorithm/string.hpp>
#include <bits/stdc++.h>
#include <iostream>
#include <string>
#include <regex>
#include <cmath>

using namespace boost::multiprecision;
using namespace std;

[SilverGekko]

Same problem here, on Red Hat 7.4.

Microsoft.VSCode.CPP.IntelliSense.Msvc.linux eats my workstation's memory.

I have tried setting the Intellisense cache size to zero and limiting the search locations for header files, but so far the only thing that works is turning off the cpptools plugin entirely.

My current solution is to just monitor what processes are using memory and kill the cpptools when it gets close to my memory limit.

[jonno85uk]

I am having to do the same thing as @SilverGekko .
Regularly killing the process.
This is on Ubuntu 18.04 VS-Code-1.39.2

[mcxiaoke]

Same issue for me. "Microsoft.VSCode.CPP.IntelliSense.Msvc.darwin" is using 6.8 GB memory, auto complete and code formatting not working sometimes. Visual Studio Code 1.40.1 macOS 10.14.6

[Colengms]

Hi @mcxiaoke . Could you try the latest insiders (0.26.2-insiders) ? This build addresses an issue with memory usage of the IntelliSense process.

[mcxiaoke]

@Colengms when 0.26.2-insiders installed, memory issue is fixed, but code autocomplete sometimes not working, so I back to 0.26.1

[michelleangela]

@Colengms when 0.26.2-insiders installed, memory issue is fixed, but code autocomplete sometimes not working, so I back to 0.26.1

@mcxiaoke, 0.26.2-insiders2 was released yesterday. With that version, could you try If the autocomplete issues still persists. If it does, could you create new issue for it with logs from the language server?

[ghost]

I have same issue with latest update to 0.26.2. It goes up to 8GB RAM usage. Linux Mint 19.2.
0.26.1 doesn't have this issue.

[logidelic]

@Colengms , @sean-mcmanus : Sorry for the delayed response. It took a while to repro again.

Attached is the callstack output from GDB for Microsoft.VSCode.CPP.Extension.linux. Let me know if you need any more info. At that moment was eating up 43GB of resident memory.

Microsoft.VSCode.CPP.Extension.linux.txt

[sean-mcmanus]

This looks like it could be the same issue as #4714 (comment) -- on Windows we crash after 4 GB.

The call stacks show parsing is going on, but nothing special -- can you get a call stack at the point where the memory is increasing fast (or confirm whether "populate_filename_cache" is on the call stack)? That call stack is after the memory is finished accumulating, right?

It doesn't repro with 0.26.1, right?

With our soon to be released 0.26.3-insiders3 we've add some special "filename cache" logging under the hidden loggingLevel of "7" to try diagnose the cause. If we can't figure out the cause (or a repro), we may need to add some aborting in the code we suspect is building the memory up if it gets "too large".

[hamidi2]

I could find a workaround on Linux at last. I'm not sure how much it makes the extension unstable, but I could use ulimit before running vscode.
First, in terminal you may run:
ulimit -v 3000000
This makes limitation of memory usage for every process which will be run in the same terminal session to about 3GB.
Then I run:
code
That's it.

[shaoxul]

ulimit -v 3000000
This might work for some case.

However, code will create several threads per user. So the total consumption of RAM is not under control in other word.

What's more, our project request for 10G RAM for building, this ulimit will make the linking failed.

[hamidi2]

Yeah, this is exactly what's wrong! 10GB of RAM! For building anything, this amount of RAM should not be required. In another way, if ulimit can't limit a process and just limit each threads of a process separately, we should be looking for a better workaround. Anyway, for me it works.

[sean-mcmanus]

@yli-magna Does the memory issue happen if you don't open a header file? Does it repro with 0.26.2?

[ghost]

Clarification: it is the extension process, not the intellisense process, that consumes this much memory. Same if I don't open a header file. I've been having this issue for a while, so I suspect 0.26.2 would have the same problem.

[Colengms]

Hi @yli-magna . Could you enable logging by setting C_Cpp.loggingLevel to Debug, and see if there are apparent correlations between what is being logged and when memory is growing excessively? We have some theories about possible culprits, but still need some clues and clarifications. Thanks for confirming that opening a header was not associated with your repro (as that is one of the theories).

[hamidi2]

2.5 million files?!!!

[logidelic]

FWIW, I still have this issue, and I do not have 2.5 million files. On the other hand, the files in my workspace are on network folders, rather than the local HD (in case that's relevant).

[hamidi2]

file size is important

[ghost]

@Colengms nothing suspicious from the debug terminal while memory is increasing. I do set "Search: Follow Symlinks" to false for my project.

[Colengms]

@yli-magna , Do you mean that there is no output at all while the memory is growing? If you do something that would normally result in logging, does it get logged? If not, could you attach a debugger to the Extension process, pause it when the issue occurs, and post the stacks here?

(Also, if anyone would like to create new threads for their issues, they may each be separate. The original issue for this thread is specific to the intellisense process).

[ghost]

@Colengms The logs look like

cpptools/textEditorSelectionChange
cpptools/getDocumentSymbols: 46
cpptools/getDocumentSymbols
cpptools/textEditorSelectionChange
cpptools/getCodeActions: 47
idle loop: reparsing the active document
Checking for syntax errors: file: ...

Am I looking at the correct log? Seems nothing interesting.
Also, I can reproduce with 0.26.2

[ghost]

It seems the cpp extension is parsing way too many files, it is a huge number, showing in Discovering files. Does the parsing follow symlinks in linux? Does it adhere to the config Search: Follow Symlinks?

[sean-mcmanus]

Yes, it follows symlinks, although it will only process the same file one time if there are loops. We don't appear to Search: Follow Symlinks. We have an issue dealing with symlinks that point to too many files at #3123 .

[logidelic]

Perhaps the extension process should be watching its own resident memory usage and should kill itself if it goes too high. I admit that this is an ugly band-aid, but until this is fixed somehow, VSCode can totally incapacitate a system. Yesterday I had to hard-power-off my system because of this.

(Of course another question is why Ubuntu's OOM killer didn't kick in properly, but that's outside the scope of VSCode...)

[sean-mcmanus]

@logidelic Yeah, we have discussed doing that, but in your case, killing the main process might just be equivalent to disabling our extension (setting intelliSenseEngine to "Disabled"). It sounds like you're still hitting the high memory usage with 0.26.3? We made some fixes we were hoping would help (#4714 ), but we were unable to get a repro. Were you able to find an older version of our extension that didn't have the high memory issue? The call stack you provided was not in code that has changed recently, so we don't have a good idea yet what could be causing it.

[hamidi2]

I've a new experience. I changed the OS from Debian 9 to Debian 10 (no upgrade, a clean install) and this solved the problem! Now I may load folders I couldn't before. I also changed DE from MATE to Cinnamon. I also changed the virtual memory size from 12GB to 100GB, although it's not so much used (4GB used once at most). I also changed the HDD to an SSD for / and swap. Maybe VSCode is using a lib which needs to be upgraded to resolve an issue?

[KuddLim]

Close vscode, delete all files under .vscode and relaunch vscode.
When vscode asks you let vscode allow intellisense for your project, deny it.
That solved my problem.

[Colengms]

The issue this was originally created to track has been addressed. We have also fixed bugs that we suspect were the cause of memory issues with the extension process referred to in this thread. There may be additional memory issues. If anyone is still seeing problems related to memory usage, please open a new issue with specific repro information, rather than adding a potentially new scenario to an existing issue.

[KuddLim]

The issue this was originally created to track has been addressed. We have also fixed bugs that we suspect were the cause of memory issues with the extension process referred to in this thread. There may be additional memory issues. If anyone is still seeing problems related to memory usage, please open a new issue with specific repro information, rather than adding a potentially new scenario to an existing issue.

I'm still having this issue with latest version of vscode when using intellisense. I'll create a new issue when I'm back to office next week.