Vscode-cpptools: Huge memory usage (11-13GB)

[mauriziopinotti]

I experienced this when opening the root of the Android firmware sources (several GB of java/cpp code):

VSCode is probably trying to compile/index all the code but it's not a good idea :)

[xwvvvvwx]

Also experienced this when I had clang and llvm as submodules in a project (macOS 10.12.1).

macOS warned me that I had run out of application memory and started pausing applications.

The processes persisted even after closing vscode.

[greazer]

Couple things. First, it's currently by design that this indexing (not compiling) continues even after VSCode stops. However, what is not by design is that it 1) Takes an excessive amount of time related to the size of the workspace that is opened 2) Eats up a ton of memory.

We do plan on making the situation much better after VSCode is closed with regard to stopping the indexing as soon as we can.

However, with regard to the massive memory use it would be great if we could get more details in how you setup your workspace so we can attempt to repro and root cause it.

[mauriziopinotti]

@greazer thanks for the feedback.

Setup is very easy on my side: just download Android sources (see https://source.android.com/source/downloading.html ), then in VSCode select "open folder" and point to the root of the downloaded tree.

I'm on a custom Android 4.3 tree but I don't think this makes some difference, it's probably just a matter of files "weight".

[ghost]

I have the same (not all the time) on fedora 25.

there is my directory structure :

• .vscode
  
  
  
  • c_cpp_properties.json
  
  
  • launch.json
  
  
  • tasks.json
  
  
• hello_world.cpp
• variables.cpp
• a.out

.vscode/c_cpp_properties.json

{
    "configurations": [
        {
            "name": "Mac",
            "includePath": ["/usr/include"],
            "browse" : {
                "limitSymbolsToIncludedHeaders" : true,
                "databaseFilename" : ""
            }
        },
        {
            "name": "Linux",
            "includePath": ["/usr/include"],
            "browse" : {
                "limitSymbolsToIncludedHeaders" : true,
                "databaseFilename" : ""
            }
        },
        {
            "name": "Win32",
            "includePath": ["c:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include"],
            "browse" : {
                "limitSymbolsToIncludedHeaders" : true,
                "databaseFilename" : ""
            }
        }
    ]
}

.vscode/launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "C++ Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceRoot}/a.out",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceRoot}",
            "environment": [],
            "externalConsole": true,
            "internalConsoleOptions": "openOnSessionStart",
            "linux": {
                "MIMode": "gdb",
                "setupCommands": [
                    {
                        "description": "Enable pretty-printing for gdb",
                        "text": "-enable-pretty-printing",
                        "ignoreFailures": true
                    }
                ],
                "preLaunchTask": "g++"
            },
            "osx": {
                "MIMode": "lldb"
            },
            "windows": {
                "MIMode": "gdb",
                "setupCommands": [
                    {
                        "description": "Enable pretty-printing for gdb",
                        "text": "-enable-pretty-printing",
                        "ignoreFailures": true
                    }
                ]
            }
        },
        {
            "name": "C++ Attach",
            "type": "cppdbg",
            "request": "attach",
            "program": "enter program name, for example ${workspaceRoot}/a.out",
            "processId": "${command.pickProcess}",
            "linux": {
                "MIMode": "gdb",
                "setupCommands": [
                    {
                        "description": "Enable pretty-printing for gdb",
                        "text": "-enable-pretty-printing",
                        "ignoreFailures": true
                    }
                ]
            },
            "osx": {
                "MIMode": "lldb"
            },
            "windows": {
                "MIMode": "gdb",
                "setupCommands": [
                    {
                        "description": "Enable pretty-printing for gdb",
                        "text": "-enable-pretty-printing",
                        "ignoreFailures": true
                    }
                ]
            }
        }
    ]
}

.vscode/tasks.json

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "0.1.0",
    "command": "g++",
    "isShellCommand": true,
    "args": ["-g", "${file}"],
    "showOutput": "always"
}

hello_world.cpp

#include <iostream> // importe les fonction d'entré-sortie'

int main()
{
    std::cout << "Hello world !" << std::endl; // affiche "Hello world !" dans la sortie standard

    std::cin.get(); // ici, met en pause le programme jusqu'à pression de la touche entré
    return 0;
}

variables.cpp

#include <iostream>
#include <string> // nécéssaire pour utiliser le type string

int main()
{
    int n(15); // crée un entier den  4 octets et l'initialise à 15
    int m = 15; // idem

    char c('A'); // crée un caractère et l'initialise à 'A'

    double pi(3.14159); //créer un nombre décimal et l'initialise à 3.14159

    bool vrai(true);

    std::string chaine("Hello world !"); // crée une chaine de caractère

    return 0;
}

I did nothing more than installing cpptools extension.

I hope it will help a little.

[sunnyps]

I can reproduce this consistently on Linux with the Chromium repository (src directory) and VS Code 1.9.0. Memory usage goes up to 60G before my workstation (64G RAM) becomes unresponsive. This does not happen on my Windows workstation. This is with stock configuration for the extension i.e. no extra include directories and the following configuration in VS Code settings.json:

{
  "files.exclude": {
    "**/.git": true,
    "**/.svn": true,
    "**/.hg": true,
    "**/.DS_Store": true,
    "**/data": true,
    "build/linux/debian_wheezy*": true,
    "build/linux/ubuntu_precise*": true,
    "native_client/toolchain": true,
    "out*": true
  },

  "search.exclude": {
    "**/node_modules": true,
    "**/bower_components": true,
    "third_party": true
  }
}

[sean-mcmanus]

I'm not able to repro that. It only uses 380 MB RAM on my Linux machine and the database is 1.4 GB. I don't know what could be causing the difference. Maybe another extension is interfering?

[sunnyps]

My DB was ~687MB. 380 MB RAM usage is about what I see on my Windows machine. On Linux the memory usage stays constant at either ~600MB, ~1700MB or ~3100MB for a while before suddenly ballooning out of control.

I purged the old DB and I've left vs code running to create a new one over the weekend.

[SakuraLife]

When I am coding a new function, the extension request huge memory, but when I do nothing,it's just fine.
What caused it?

[sean-mcmanus]

@SakuraLife What exactly is the size of "huge memory"? Editing a file will cause intelliSense error squiggle checking to occur.

[SakuraLife]

@sean-mcmanus My total memory is only 8GB. And when I do nothing, it's only need 300~400MB, when coding it, it need more than 5GB memory and more than 2GB swap space before I killing it, and My database is 1GB.
and this is my c_cpp_properties.json

{
  "configurations":
  [
    {
      "name": "Linux",
      "includePath":
      [
        "/usr/include/",
        "/usr/include/c++/7.2.0/",
        "/usr/include/c++/7.2.0/backward/",
        "/usr/include/c++/7.2.0/x86_64-pc-linux-gnu/",
        "/usr/include/sysdev_headers/",
        "${workspaceRoot}/"
      ],
      "browse":
      {
        "limitSymbolsToIncludedHeaders": false,
        "databaseFilename": "/home/inochi/Programming/VScode/.vscode/",
        "path":
        [
          "/usr/include/",
          "/usr/include/c++/7.2.0/",
          "/usr/include/c++/7.2.0/backward/",
          "/usr/include/c++/7.2.0/x86_64-pc-linux-gnu/",
          "/usr/include/sysdev_headers/",
          "/home/inochi/Programming/VScode/libcxx-4.0.1.src/include/",
          "{workspaceRoot}/"
        ]
      },
      "intelliSenseMode": "clang-x64"
    }
  ],
  "version": 3
}

[sean-mcmanus]

@SakuraLife 300-400 MB is expected, but 5 GB memory usage is not. This is with the Microsoft.VSCode.Cpp.IntelliSense.Msvc.linux process, right? It looks like parsing is hitting some bug where it's not cleanup memory or is entering some infinite processing. If you could isolate the code that is leading to this behavior, that would help us fix it. I assume it doesn't repro with a simple file, right? Your databaseFilename is a path with no name...hopefully we handle that case correctly, but you should double check. Your browse.path has redundant paths in it, since it's recursive, but we've added an automatic fix for that in our next release.

[SakuraLife]

@sean-mcmanus You're right. I think it uses so much memory maybe because I'm changing the code in includePath and browse path(/usr/include/sysdev_headers/)(I create a link to this path in my workspace to make easy to change).And because these occured when I use default database path. So I change it to see how big the database is. I have known there are redundant paths, but it tell me some dependency is not find if I don't add these paths.

[sean-mcmanus]

@SakuraLife The dependency not found message should only occur due to the includePath setting and not the browse.path setting, which is recursive, e.g. /usr/include/c++/7.2.0/backward/ is needed for the includePath, but is already used from "/usr/include/c++/7.2.0/ in the browse.path. Changing that will not reduce the memory usage though, just the time for the main process to reach an idle state.

[neuthral]

I found this was causing my Debian setup to crash all the time, switching back to Sublime, i cant work with these crashes

[sean-mcmanus]

@neuthral If you're on Debian 7 or earlier, then the platform is unsupported by our extension.

[sean-mcmanus]

We fixed a bunch of issues that could be causing this. Let us know if this still repros in the latest version 0.14.6.

[xgdgsc]

I' m on 0.14.6 and opened 3 folders of code. Don' t know if it is normal.

[sean-mcmanus]

@xgdgsc This appears to be "normal" for large translation units, although we want to reduce the memory usage. This bug's issue was for one process using 11 GB's of memory, but your largest is 660 MB. You could file a new issue to reduce the memory usage more.

[bobbrow]

@xgdgsc, per folder we try to keep the total memory usage for IntelliSense under 1 GB, so we will shut down older processes if you're opening a lot of files at once. For 3 folders opened that would amount to 3 GB or so (the cap is a bit fuzzy).

Are you able to see the parent process of the IntelliSense processes? Those 600MB processes might have been orphaned. We're still not 100% perfect at shutting down all IntelliSense processes when the extension shuts down, but we have a fix coming in the next release that should help.

[xgdgsc]

Thanks for the effort. That sounds reasonable.

[Zalez95]

Hi, I'm new with VSCode and I'm having this same issue in Linux Mint 18.3 in 64 bits (based on Ubuntu 16.04) with 8GB of RAM. The VSCode C++ extension starts using memory until my PC runs out of it, I even have to sandbox the app because when this happens my system becomes unresponsive.

Pls send help

[sean-mcmanus]

@Zalez95 We haven't received any reports of 3-4 GB memory usage since October. What version of cpptools are you using? 0.14.6? Does it repro with the insiders build: https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.15.0-insiders ? We need more repro info in order to fix this. I assume it doesn't repro with a simpler project?

[Zalez95]

Hi @sean-mcmanus,

Yes, I'm currently using the 0.14.6 version of cpptools, but I could try to install that one and work with it just to see if this problem happens again, because it seems that it happens randomly in this version (also, the memory was limited to max 4GB in that screenshot, if i hadn't limited it, Cpptools will had continued using memory until my computer had runned out of it).

On the other hand, It hasn't happened to me with smaller projects yet.

[nico87]

Same problem here! Ubuntu 14.04. It worked fine until I updated to intellisense 0.14.6.

[sean-mcmanus]

@nico87 We're releasing 0.15.0 tomorrow which has an updated IntelliSense parser. Let us know if it still repros and any hints on how to repro the memory issue. What was your previous version? 0.14.5 or something earlier? We haven't received many reports of regressions due to 0.14.6.

[nico87]

I was on 0.14.5 until yesterday, when I updated.
Looking forward to 0.15.0! :-)

[Abdullah-AlAttar]

still having this issue.

[sean-mcmanus]

@Abdullah-AlAttar Can you open a new issue with more repro and symptom details, such as via attaching a debugger and getting a call stack when the memory is increasing too much?

[hamidi2]

Sorry to say that, but the essential problem is that it's from Microsoft! We've some similar experiences with VS Intellisense in Windows. For this, we had to disable the built-in Intellisense and use the Whole Tomato Visual Assist which would be even better, while using less memory. The problem is that you don't count on memory as a valuable resource which is shared with other processes. VSCode should be a portable application between all computers with different available resources. If I would be a developer in the team, I would cache only indexes in memory, not the whole data of Intellisense! Memory is required by other processes too and you should optimize using it, not to look at it as a belonging treasure! Once Mr. Bill Gates told that 640K should be enough, but it seems that the policy has changed so rapidly. The policy should be this: Never use memory unless it's really necessary. The whole data should remain there in a file and be accessed only when needed by having a good and as small as possible index in memory.

[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.

[sean-mcmanus]

@hamidi2 VS on Windows (and our extension on Windows) is limited to 2-4 GB per process already, in which case the process would crash from an out of memory, but for VS Code on Linux, it could keep using more memory without your workaround. I can't tell from the info provided if the main process or the IntelliSense process is using memory or if you're using 0.26.3-insiders2, which has a known memory issue in unknown circumstances.

[hamidi2]

My workaround was what I tested and worked on Debian 9. I never used vs code on Windows.