Vscode-cpptools: High CPU load on "idle" VSCode with launcher configured

[darrenkenny]

• VSCode Version: Code - Insiders 1.19.0-insider (73830a36872aa1c168c085dad8cc6e2e1a05ff45, 2017-11-13T15:41:43.967Z)
• OS Version: Linux x64 4.12.12-1.el7ocl.x86_64
• Extensions:

Extension|Author (truncated)|Version
---|---|---
RPMSpec|1do|0.1.0
rainbow-brackets|2gu|0.0.6
vscode-markdownlint|Dav|0.11.0
xml|Dot|1.9.2
EditorConfig|Edi|0.11.1
output-colorizer|IBM|0.1.2
code-settings-sync|Sha|2.8.5
reflow-paragraph|Tro|1.1.0
shell-launcher|Tyr|0.1.4
sort-lines|Tyr|1.3.0
html-css-class-completion|Zig|1.14.0
project-manager|ale|0.23.0
alignment|ann|0.3.0
code-gnu-global|aus|0.2.2
git-easy|bib|1.9.1
path-intellisense|chr|1.4.2
gitignore|cod|0.5.0
githistory|don|0.2.3
gitlens|eam|6.1.0
tslint|eg2|1.0.21
vscode-npm-script|eg2|0.3.3
LogFileHighlighter|emi|1.2.0
json-tools|eri|1.0.2
code-runner|for|0.8.3
symbolstreeview|igb|0.1.5
Hg|jak|0.0.4
ctags-support|jay|1.0.18
docthis|joe|0.6.0
Go|luk|0.6.67
cpp-symbols|mir|0.0.1
vscode-clang|mit|0.2.2
hg|mrc|1.2.3
python|ms-|0.8.0
azure-account|ms-|0.2.2
cpptools|ms-|0.14.2
indent-rainbow|ode|0.7.2
vscode-code-outline|pat|0.0.12
remote-vscode|raf|1.1.0
vscode-icons|rob|7.17.0
partial-diff|ryu|0.5.0
guides|spy|0.9.0
code-spell-checker|str|1.4.12
spellchecker|swy|1.2.13
python|tht|0.2.3
shellcheck|tim|0.2.1
vscode-todo-highlight|way|0.5.11
change-case|wma|1.0.0
highlight-trailing-white-spaces|yba|0.0.2

(11 theme extensions excluded)

---

Steps to Reproduce:

1. I have a workspace for the Qemu project, and set up a launch.json file.
2. Since then I noticed the load on my machine rocketed, and it appears to be VSCode
   and the CPP plugin that is causing it, and this is from startup, I've not even launched
   a debugging session yet (which makes me thing the launch.json is not the real cause,
   just something that caused me to look at the CPU usage more closely)

.

I have attached the console log from VSCode, which is pretty much repeating the text, in quick succession:
vscode-console.log

t.log @ console.ts:123
t._logExtensionHostMessage @ extensionHost.ts:376
(anonymous) @ extensionHost.ts:201
emitTwo @ events.js:106
emit @ events.js:194
process.nextTick @ internal/child_process.js:766
_combinedTickCallback @ internal/process/next_tick.js:73
_tickCallback @ internal/process/next_tick.js:104
console.ts:123 [Extension Host] TypeError: Cannot read property 'stop' of undefined
    at DefaultClient.dispose (/home/darrenk/.vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/out/src/LanguageServer/client.js:505:35)
    at ClientCollection.replace (/home/darrenk/.vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/out/src/LanguageServer/clientCollection.js:88:20)
    at Object.closed (/home/darrenk/.vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/out/src/LanguageServer/client.js:189:52)
    at LanguageClient.handleConnectionClosed (/home/darrenk/.vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/node_modules/vscode-languageclient/lib/client.js:1868:55)
    at LanguageClient.handleConnectionClosed (/home/darrenk/.vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/node_modules/vscode-languageclient/lib/main.js:78:15)
    at closeHandler (/home/darrenk/.vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/node_modules/vscode-languageclient/lib/client.js:1852:18)
    at CallbackList.invoke (/home/darrenk/.vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/node_modules/vscode-jsonrpc/lib/events.js:71:39)
    at Emitter.fire (/home/darrenk/.vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/node_modules/vscode-jsonrpc/lib/events.js:135:36)
    at closeHandler (/home/darrenk/.vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/node_modules/vscode-jsonrpc/lib/main.js:221:26)
    at CallbackList.invoke (/home/darrenk/.vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/node_modules/vscode-jsonrpc/lib/events.js:71:39)
    at Emitter.fire (/home/darrenk/.vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/node_modules/vscode-jsonrpc/lib/events.js:135:36)
    at StreamMessageReader.AbstractMessageReader.fireClose (/home/darrenk/.vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/node_modules/vscode-jsonrpc/lib/messageReader.js:135:27)
    at Socket.<anonymous> (/home/darrenk/.vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/node_modules/vscode-jsonrpc/lib/messageReader.js:188:62)
    at emitOne (events.js:101:20)
    at Socket.emit (events.js:191:7)
    at Pipe._handle.close [as _onclose] (net.js:510:12) (at CallbackList.invoke (/home/darrenk/.vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/node_modules/vscode-jsonrpc/lib/events.js:74:25))
t.log @ console.ts:123
t._logExtensionHostMessage @ extensionHost.ts:376

[bobbrow]

Thank you for reporting this. Is this CentOS7? We don't currently have language server support for that distro, but the crash is a regression and I will add a fix for it.

[darrenkenny]

It is Oracle Linux 7.4, which is largely based on RHEL 7.

Ive been running vscode for a good while, usually Insider builds and not seen this before.

Thanks,

Darren

[sean-mcmanus]

RHEL 7 is unsupported by our extension, so Oracle Linux 7.4 is probably as well, due to not having glibc 2.18. VS Code itself supports it, but our language service process won't run without some workaround for the missing glibc 2.18 ( https://github.com/Microsoft/vscode-cpptools/issues/19 ).

[s-martin]

I noticed this behavior as well on CentOS 7.
In the past, when you did not have the workaround described in #19 in place, the Language Server simply didn't work.
Now since VSCode 1.18 it's unusable under CentOS 7, because of the high CPU load, if the #19 workaround is not in place.

[darrenkenny]

Looks like it is the same issue as #19, in that it requires glibc 2.18.

I followed the same w/around as in #19, except that the file that needed patching was different in version 0.14.2 (which is installed in the insider builds now), and is now looking like:

--- .vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/out/src/LanguageServer/client.js~       2017-11-10 02:53:27.038957553 +0000
+++ .vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/out/src/LanguageServer/client.js        2017-11-15 14:32:59.513558321 +0000
@@ -517,7 +517,8 @@
     let extensionProcessName = 'Microsoft.VSCode.CPP.Extension';
     let plat = process.platform;
     if (plat == 'linux') {
-        extensionProcessName += '.linux';
+        //extensionProcessName += '.linux';
+        extensionProcessName += '.linux.sh';
     }
     else if (plat == 'darwin') {
         extensionProcessName += '.darwin';
@@ -567,4 +568,4 @@
         return Promise.resolve();
     }
 }

And creating the file ~/.vscode-insiders/extensions/ms-vscode.cpptools-0.14.2/bin/Microsoft.VSCode.CPP.Extension.linux.sh to look like:

#!/bin/bash
exec /opt/glibc-2.18/lib/ld-linux-x86-64.so.2 \
        --library-path /opt/glibc-2.18/lib:/lib64:/lib64  \
   "${0//.sh/}" ${1+"$@"}

That works for me now.

A page I found in relation to this kind of thing w.r.t. glibc, etc suggested that really it would be better to statically link the binary to w/around this issue:

https://developers.redhat.com/blog/2016/02/17/upgrading-the-gnu-c-library-within-red-hat-enterprise-linux/

[bobbrow]

I believe I have a fix for this. The callstack you shared was easy to address, but the issue with the high CPU load may or may not be fixed with our next update. I identified a place where an exception can be thrown if the language server fails to launch by emulating your setup (I don't have an unsupported distro installed at this time) and I suspect that VS Code was constantly attempting to respawn our extension when it crashed. We will be catching this exception starting in the next update and turning the extension into a no-op provider for IntelliSense events.

[bobbrow]

This should be fixed with version 0.14.3 (#19 will be fixed in the next update)