Vscode-cpptools: [linux] 0.26.0-insiders2 eating entire RAM

[Finkman]

Type: General

Describe the bug

• OS and Version: Ubuntu 18.04
• VS Code Version: 1.38.1
• C/C++ Extension Version: 0.26.0-insiders2

After vs code automatically update the extension to 0.26.0-insiders2, my pc got stuck. I saw the the extension is utilizing all of my memory and the system starts swapping.

There is even no chance to take a screenshot, since the snipping tool crashes under that conditions.

To Reproduce
Install 0.26.0-insiders2 and wait.

Expected behavior
Expect nothing to happen.

Additional context
Because vs code is automatically updating the extension I turned off 'automatic update' for extensions, again

[sean-mcmanus]

Is anyone able to provide more repro info? We're not able to repro this yet. Does it only repro with certain projects or configurations? i.e. does it repro with an simple int main(){ return 0; } project or does adding #include to gcc headers of a certain gcc version? Is this with a C or C++ project? Are you using compileCommands or configurationProvider? Is it reproing with any open source projects we can try?

Could someone enable debug logging: https://code.visualstudio.com/docs/cpp/enable-logging-cpp and see if that gives any info? How fast does the memory increase? What is the CPU usage like?

We also changed the types of files that we treat as C++ for parsing. This could cause files to be parsed that weren't parsed previously, and those file could cause our parser to hit a problem.

Our guess is that our code to handle the nested document symbols is hitting some unexpected case. If it's a document symbol issue, I wouldn't the #includes would matter, only the code in the file that is opened.

Is anyone able to attach a debugger to get a call stack? There is a regression crash involving vector and LocalizeDocumentSymbol that we are investigating which may be the same issue as this.

Has anyone hit this on Mac, clang on Linux, or on Windows (on any compiler)?

Is this with a particular VS Code display language? We added support for multiple languages with 0.26.0-insiders.

[Finkman]

Sorry for leaving so many open questions. I hope to find some time to investigate in this next week.
All I can answer is, that the on my workstation the extension occupied all of the 16GB within ~5s.

[sean-mcmanus]

Sure, if anyone could try doing the repro with 0 files open at startup, that could help narrow down the cause, i.e. our document symbol code only runs when a file is opened/active, but our tag parser code runs on workspace open.

[sean-mcmanus]

FYI, we've detected a bug involving nested namespaces that have children with the same name that can lead to a stack overflow crash (https://github.com/microsoft/vscode-cpptools/issues/4390), but we haven't been able to get a repro for the high memory usage issue yet.

[sean-mcmanus]

I finally got a repro:

namespace foo {
    namespace bar {
        namespace baz {
            int qux = 42;
        }
    }
}


namespace foo::bar::baz
{
}

[abdullahwaqar]

Sorry for leaving so many open questions. I hope to find some time to investigate in this next week.
All I can answer is, that the on my workstation the extension occupied all of the 16GB within ~5s.

I can confirm this as it is taking all the swap memory too and the version i have is not even the insider version.

[enbyted]

Any Idea which version doesn't have this bug? I've tried 0.25.0, 0.25.1, latest insiders and all of them cause the same problem in my project.
Strange thing is that this started happening few hours after updating to 0.26.0-insiders2 and I can't correlate this to any code change during that time.

My details:

• OS: Ubuntu 19.04
• VS Code: 1.39.0-insider
• Using vector-of-bool cmake tools as configuration provider
• Qt project (which includes Qt's XML files and moc generated files)
• I'm using C++17 style namespace short::nested::namespace::syntax

It appears that this kind of thing is triggering it, although I believe this is not enough on it's own to reproduce.

namespace foo::bar::baz
{
  namespace Ui { class SomeUiClass; }

  class SomeUiClass : public QWIdget
  {
    Q_OBJECT
    Ui::SomeUiClass *ui;
    // rest of class
  };
}

The problem appeared when I did a filesystem copy of .cpp, .ui, .h files to duplicate a widget and started renaming things. The new files weren't yet added to CMakeLists.txt file and the first memory leak happend after showing notification that it doesn't know this file (because cmake-tools didn't yet know about it).
Now this happens even on a source version (I mean my project's source) from before the bug was triggered and after downgrading the plugin. Although this doesn't happen when opening a folder that contains different (non-Qt) project. Just opening workspace and not opening any files is enough for cpp tools to eat all the memory.

I hope this somehow helps you find the cause, if you need more details I'll try to help, though I don't have much time recently.

Oh and it takes about 4-5s to fill up 14,5GB of ram (I've got 16GB, ~1,5 used when cpp tools are disabled) and about 15 minutes to fill up 50GB swap space (after that OOM killer does it's job). I'm running Ryzen 1700 with B350 chipset and swap is on dedicated SSD for swap and temp files (not used in this case). Of course during the filling of swap space the system is unresponsive.

[Finkman]

so maybe using CMake is one thing we all have in common.
Maybe the bug come from an incompatibility with cmake (ep the cmake extensions) and therefore is also entertaining us when rolling back to a previous version of the c/cpp extension...
(Just thinking out loud)

[ArekSredzki]

I use Bazel so I don’t think that CMake is relevant

[mustafakemalgilor]

I got the same problem too, eats up all of available ram in seconds.

My details:

OS: Debian Sid
VS Code Details:

• Version: 1.39.0-insider
• Commit: c8252b63f547674d2faf361d4181bb76b0b5f81a
• Date: 2019-10-04T09:24:45.417Z
• Electron: 4.2.10
• Chrome: 69.0.3497.128
• Node.js: 10.11.0
• V8: 6.9.427.31-electron.0
• OS: Linux x64 4.19.0-4-amd64

VS Code Extensions:

• Arduino 0.2.27
• Ayu (theme) 0.18.0
• C/C++ (cpptools) 0.26.0-insiders2
• CMake 0.0.17
• CMake Tools 1.1.3
• C++ Intellisense 0.2.2
• markdownlint 0.30.2

Toolchain Information

• GCC 9.2.1

Project Info
Native C++ project (using CMake as build system), C++2a standard, I'm using regular nested namespaces in header files, c++17 style short nested namespace syntax in cpp files.

Problem triggers when a cpp file with c++17 style short namespaces is in focus.

Screenshot of process list : here

[sean-mcmanus]

@abdullahwaqar We're not aware of any issue like this with 0.25.1, so setting C_Cpp.updateChannel to "Default" is the recommended workaround until we can get a fix (probably later today). Maybe VS Code is still using the insider version? Or if you manually switched to 0.25.1 without changing the updateChannel setting, it could be auto-updating back to 0.26.0-insiders2. If it really does repro with 0.25.1, then it would be a different issue that we are not aware of a repro for yet.

[Finkman]

@sean-mcmanus for me, switching back to 0.25.1 is fine.

[enbyted]

@sean-mcmanus
for me installing the -insiders2 version triggered the bug and downgrading (with updateChannel on Default) doesn't fix the issue.

Though the same codebase in non-insider vscode with 0.25.1 cpptools doesn't repro (this one has never seen -insiders2).

Something is persistent here somehow. It's a normal - local - workspace with cmake c++ project and two ReactJS / typescript projects.

[mustafakemalgilor]

0.25.1 works fine for me too. had to disable plugin auto-update feature.

On Mon, 7 Oct 2019, 21:39 Sean McManus, [e-mail] wrote:

@abdullahwaqar https://github.com/abdullahwaqar We're not aware of any
issue like this with 0.25.1, so setting C_Cpp.updateChannel to "Default" is
the recommended workaround until we can get a fix (probably later today).
Maybe VS Code is still using the insider version? If it really does repro
with 0.25.1, then it would be a different issue that we are not aware of a
repro for yet.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-cpptools/issues/4386?email_source=notifications&email_token=ABCHY6CFPYUJIRSHZHY2AB3QNN65BA5CNFSM4I5OYGQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEARL77Q#issuecomment-539148286,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABCHY6CAXYSOY5TRZXKXTALQNN65BANCNFSM4I5OYGQQ
.

[sean-mcmanus]

@enbyted VS Code may be caching the insider extension version? If you do a Reload Windows does it show "0.25.1" as the C/C++ extension.

[enbyted]

@sean-mcmanus Yes it does. I've tried reloading, restarting, rebooting. It's weird, cause I can't duplicate the issue on another machine.
I'll try purging and installing vscode-insiders again, maybe that'll clear whatever got stuck for me.
Seems like some random problem, not really related to this issue, or caused by it, no idea. In any case, I've got working non-insiders vscode, so it's not a big issue for me - sometimes nasty bugs happen, that's what we get for beta testing.

EDIT: After purge and reinstall it's not crashing on 0.25.1

[daravi]

Same here. On CentOS 7 and disabling auto-update on 0.25.1 has solved it so far. (hi @ArekSredzki!)

[sean-mcmanus]

The memory usage/crash problem is fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/0.26.0-insiders3 .