[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 (#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
{
}