Version 0.10.3 uses a full core on CPU

[q42jaap]

Version 0.10.3 uses up 100% cpu on my macbook pro.
Especially the Electron Helper

[alexdima]

@q42jaap Can you please provide additional details.

Does this happen when opening a specific folder? Does this happen when opening VSCode without a folder (Cmd+Shift+N)? Anything you can add to help us reproduce

[q42jaap]

Im using the following line in .bash_profile:
code () { VSCODE_CWD="$PWD" open -n -b "com.microsoft.VSCode" --args $* ;}

I use that to code . in the directory. I leave the editor open voor a long time. And then I notice my Mac is running low on power. It's also getting hot, CPU is high on the Electron Helper subprocess.

It's difficult to say how to repro, I can't always get that to happen (fortunately).

tree | wc -l gives 25876 (406 of my own files/dirs, the rest are node_modules, I'm using npm 3)

[bpasero]

@q42jaap what workspace do you open with code?

[q42jaap]

I'm opening a directory in which I've checked out our private git repo. Not a particularly big project.
We use nodejs 5 for backend and babel ES6 code for the frontend.

Are there steps (suchs as logs or dumps) I can take and submit (privately) to Microsoft?

[bpasero]

@q42jaap well it would be interesting if this happen on a different folder too, maybe you could give it a try. Does the CPU go to 100% right after you open the folder?

[q42jaap]

It does not always happen, and it does not happen immediately. I'm currently in the process of reinstalling vscode, which is going to take a while due to slow connection.

[ragebiswas]

I'm seeing the same on 0.10.5. Strangely, I didn't see this prior to 0.10.5 - any ideas?

[bpasero]

Again, if there is a repository we could clone to reproduce the behaviour, please let us know.

[planetexpress69]

Same her. As of 0.10.5 ElectronHelper misbehaves and eats up all of my cpu cycles.
Happens on a small Ember project with a fairly big nodes_module directory. node_module and bower_components are already excluded from search. Is there a way to turn back to 0.10.3 without building it by yourself?
I am running on OS X 10.11.2.

Update: "files.ignore" does not help. Looks like ElectronHelper is trying to allocate all the memory it can get! Once its done eating up all memory it crashes. Incompatibility to Node 5.2.0?

brew upgrade node (to 5.3.0) does not help either...

Process: Electron Helper [1700] Path: /Applications/Visual Studio Code.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS/Electron Helper Identifier: Electron Helper Version: 0 Code Type: X86-64 (Native) Parent Process: Electron Helper [1696] Responsible: Electron Helper [1700] User ID: 501

Date/Time: 2015-12-21 15:18:30.508 +0100
OS Version: Mac OS X 10.11.2 (15C50)
Report Version: 11
Anonymous UUID: 41A4E3F5-2072-E603-8E66-FF147EECEDD3

Time Awake Since Boot: 7100 seconds

System Integrity Protection: disabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff8f973002 pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff90caf5c5 pthread_kill + 90
2 libsystem_c.dylib 0x00007fff869d16e7 abort + 129
3 libnode.dylib 0x00000001049b2189 0x1049a4000 + 57737
4 libnode.dylib 0x0000000104cf2d12 v8::internal::V8::FatalProcessOutOfMemory(char const, bool) + 594
5 libnode.dylib 0x0000000104e8c788 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) + 408
6 libnode.dylib 0x00000001050de89d v8::internal::Runtime_AllocateInTargetSpace(int, v8::internal::Object_, v8::internal::Isolate_) + 109
7 ??? 0x000016c575e06355 0 + 25037342008149

[bpasero]

For those that see high CPU use, please identify the arguments for the proces (e.g. ps aux | grep ) so that we know which of the processes that Code spawns is the one in charge.

[planetexpress69]

@bpasero
Started Code two minutes ago. Activity monitor reports already a memory usage of 1.25 GB... This is what ps says:
martin@mbp13 oi [master] $ ps aux | grep Electro
martin 987 115,7 13,1 4206388 1099208 ?? R 10:09am 2:16.77 /Applications/Visual Studio Code.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS/Electron Helper /Applications/Visual Studio Code.app/Contents/Resources/app/out/bootstrap --type=watcherService
martin 988 0,0 0,0 2464436 3184 ?? S 10:09am 0:00.01 /Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Resources/crashpad_handler --database=/tmp/VSCode Crashes --url=https://ticinocrashreporter.azurewebsites.net/crash --handshake-fd=59
martin 981 0,0 0,7 3203928 54996 ?? S 10:09am 0:00.60 /Applications/Visual Studio Code.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS/Electron Helper /Applications/Visual Studio Code.app/Contents/Resources/app/out/bootstrap --type=pluginHost
martin 980 0,0 1,7 4519136 145132 ?? S 10:09am 0:03.12 /Applications/Visual Studio Code.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS/Electron Helper --type=renderer --no-sandbox --lang=en-US --node-integration=true --enable-delegated-renderer --num-raster-threads=2 --gpu-rasterization-msaa-sample-count=8 --content-image-texture-target=3553 --video-image-texture-target=3553 --channel=974.1.633953805
martin 979 0,0 0,5 3194512 39524 ?? S 10:09am 0:00.30 /Applications/Visual Studio Code.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS/Electron Helper /Applications/Visual Studio Code.app/Contents/Resources/app/out/bootstrap --type=SharedProcess
martin 975 0,0 0,5 2711288 40136 ?? S 10:09am 0:00.25 /Applications/Visual Studio Code.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS/Electron Helper --type=gpu-process --channel=974.0.1109795083 --no-sandbox --supports-dual-gpus=false --gpu-driver-bug-workarounds=13,24,29,32,41,45,52,58 --gpu-vendor-id=0x8086 --gpu-device-id=0x0166 --gpu-driver-vendor --gpu-driver-version
martin 974 0,0 0,8 3395268 65068 ?? S 10:09am 0:01.38 /Applications/Visual Studio Code.app/Contents/MacOS/Electron
martin 1060 0,0 0,0 2432788 588 s001 R+ 10:11am 0:00.00 grep Electro

[planetexpress69]

@bpasero After start (with loading my Ember project automatically ), I've got six Electron Helper processes. One of them ist using approx 120% CPU to allocate memory. It stops eating CPU cycles after allocation aroun 1.28 GB RAM. I already excluded the usual suspects (node_modules, tmp, bower_components) with "files.exclude"...
Thx in advance, Martin

[alexdima]

Here is the output formatted (according to http://superuser.com/a/117921):

USER    PID   %CPU   %MEM      VSZ      RSS TTY  STAT  START    TIME     COMMAND
martin  987  115,7   13,1  4206388  1099208 ??    R    10:09am  2:16.77  /Applications/Visual Studio Code.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS/Electron Helper /Applications/Visual Studio Code.app/Contents/Resources/app/out/bootstrap --type=watcherService
martin  988    0,0    0,0  2464436     3184 ??    S    10:09am  0:00.01  /Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Resources/crashpad_handler --database=/tmp/VSCode Crashes --url=https://ticinocrashreporter.azurewebsites.net/crash --handshake-fd=59
martin  981    0,0    0,7  3203928    54996 ??    S    10:09am  0:00.60  /Applications/Visual Studio Code.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS/Electron Helper /Applications/Visual Studio Code.app/Contents/Resources/app/out/bootstrap --type=pluginHost
martin  980    0,0    1,7  4519136   145132 ??    S    10:09am  0:03.12  /Applications/Visual Studio Code.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS/Electron Helper --type=renderer --no-sandbox --lang=en-US --node-integration=true --enable-delegated-renderer --num-raster-threads=2 --gpu-rasterization-msaa-sample-count=8 --content-image-texture-target=3553 --video-image-texture-target=3553 --channel=974.1.633953805
martin  979    0,0    0,5  3194512    39524 ??    S    10:09am  0:00.30  /Applications/Visual Studio Code.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS/Electron Helper /Applications/Visual Studio Code.app/Contents/Resources/app/out/bootstrap --type=SharedProcess
martin  975    0,0    0,5  2711288    40136 ??    S    10:09am  0:00.25  /Applications/Visual Studio Code.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS/Electron Helper --type=gpu-process --channel=974.0.1109795083 --no-sandbox --supports-dual-gpus=false --gpu-driver-bug-workarounds=13,24,29,32,41,45,52,58 --gpu-vendor-id=0x8086 --gpu-device-id=0x0166 --gpu-driver-vendor --gpu-driver-version
martin  974    0,0    0,8  3395268    65068 ??    S    10:09am  0:01.38  /Applications/Visual Studio Code.app/Contents/MacOS/Electron
martin 1060    0,0    0,0  2432788      588 s001  R+   10:11am  0:00.00  grep Electro

Here is the output trimmed:

   %CPU   %MEM      VSZ      RSS  STAT   TIME     COMMAND
  115,7   13,1  4206388  1099208   R    2:16.77  [watcherService]
    0,0    0,0  2464436     3184   S    0:00.01  [crashHandler]
    0,0    0,7  3203928    54996   S    0:00.60  [extensionHost]
    0,0    1,7  4519136   145132   S    0:03.12  [renderer]
    0,0    0,5  3194512    39524   S    0:00.30  [sharedProcess]
    0,0    0,5  2711288    40136   S    0:00.25  [gpuProcess]
    0,0    0,8  3395268    65068   S    0:01.38  [mainProcess?]

@bpasero Looks like the file watcher?

[bpasero]

@planetexpress69 does CPU ever go down, is it only initially?

[planetexpress69]

Hi Benjamin, CPU goes down after allocation approx 1,25 GB of RAM. Takes around four minutes on my „101“ (MacBook Pro (13 Zoll, Mitte 2012), 2.9 GHz Core i7).
Regards,
Martin

Am 12.01.2016 um 10:56 schrieb Benjamin Pasero [email protected]:

@planetexpress69 https://github.com/planetexpress69 does CPU ever go down, is it only initially?

—
Reply to this email directly or view it on GitHub #1009 (comment).

[bpasero]

Can people seeing this issue with a JavaScript workspace please give our insiders build a try (https://code.visualstudio.com/insiders) and enable Salsa: https://github.com/Microsoft/vscode-docs/blob/master/release-notes/latest.md#javascript---salsa-preview

[kevinkucharczyk]

@bpasero: I am still experiencing the issue on the Insiders build with Salsa enabled.

OS X El Capitan Version 10.11.1 (15B42)

[kanekv]

I'm seeing the same behavior, Electron helper process constantly allocating more and more memory and then crushes at some point and start over. CPU consumptions is 350% around that time.
OS X Yosemite.

[bpasero]

Closing as duplicate of #774. We believe the issue to be when having a large folder (gigabytes) and installing the file watcher on it.

[bpasero]

thanks, we figured that it must be something else. is it possible to share the workspace with me go reproduce?

[kanekv]

@bpasero looks like this issue is specific to a project, unfortunately I can't share it. Is there anything else I can help to debug it?

[planetexpress69]

Hi there,

undefined as well.

martin@mbp13 scripts [master] $ ./code.sh undefined [08:52:23] Using gulpfile ~/Desktop/vscode/gulpfile.js [08:52:23] Starting 'electron'... [08:52:23] Finished 'electron' after 741 μs [2333:0309/085225:INFO:CONSOLE(199)] "%c[Extension Host] %cdebugger listening on port 5870", source: file:////Users/martin/Desktop/vscode/out/vs/workbench/services/thread/electron-browser/threadService.js (199)

Am 08.03.2016 um 11:53 schrieb Benjamin Pasero [email protected]:

@q42jaap https://github.com/q42jaap @ragebiswas https://github.com/ragebiswas @Kane-Sendgrid https://github.com/Kane-Sendgrid @kevinkucharczyk https://github.com/kevinkucharczyk @planetexpress69 https://github.com/planetexpress69 is one of you able to do a little experiment? I am speculating that maybe our library for file watching is failing. The steps would be:

setup to run vscode out of our sources as described at https://github.com/Microsoft/vscode/wiki/How-to-Contribute https://github.com/Microsoft/vscode/wiki/How-to-Contribute
copy the contents of Applications/Visual Studio Code.app/Contents/Resources/app/node_modules/chokidar into the sources at ./node_modules/chokidar (replace the entire folder)
open ./node_modules/chokidar/lib/fsevents-handler.js from the sources and insert console.log(fsevents) in line 9
run code out of sources with ./scripts/code.sh and send me the output
For me (since fsevents works ok), I get this:

~/Development/monaco/scripts> ./code.sh
[10:07:53] Using gulpfile ~/Development/monaco/gulpfile.js
[10:07:53] Starting 'electron'...
[10:07:53] Finished 'electron' after 1.28 ms
[9931:0308/100756:INFO:CONSOLE(199)] "%c[Extension Host] %cdebugger listening on port 5870", source: file:////Users/bpasero/Development/monaco/out/vs/workbench/services/thread/electron-browser/threadService.js (199)
[9931:0308/100802:INFO:CONSOLE(199)] "%c[Extension Host] %cdebugger listening on port 5870", source: file:////Users/bpasero/Development/monaco/out/vs/workbench/services/thread/electron-browser/threadService.js (199)
~/Development/monaco/scripts> ./code.sh
{ [Function: watch]
getInfo: [Function: getInfo],
FSEvents: [Function: FSEvents],
Constants:
{ kFSEventStreamEventFlagNone: 0,
...
If something goes wrong, I would expect fsevents to print as undefined. In that case, can you put another console.log inside the try/catch block of line 7 to see what the error is loading that native module?

Thanks!

—
Reply to this email directly or view it on GitHub #1009 (comment).

[planetexpress69]

Can’t share my workspace, but either 0.10.10 or my upgrade to ember 2.4 and rebuilding the whole node_modules („hairy fireball of death®“) fixed the problem for me.
M.

Am 08.03.2016 um 22:37 schrieb Benjamin Pasero [email protected]:

thanks, we figured that it must be something else. is it possible to share the workspace with me go reproduce?

—
Reply to this email directly or view it on GitHub #1009 (comment).

[trojanfoe]

I'll add a "me too" to this issue. I am using VSCode with Unity and the project size is small, yet it's still chomping at my CPU (MBP, Yosemite).

[bpasero]

@trojanfoe able to share this workspace with me? what OSX are you on?

[bpasero]

@Kane-Sendgrid @planetexpress69 very sorry, I realized my instructions were not good and I have updated them. the output we see on the console is coming from a different use of chokidar, not the one from VS Code. the new instructions are slightly different but not much and we can see if chokidar is running by looking at the developer console within Code. Can you retry please?

[kanekv]

@bpasero for me it's only logging: debugger listening on port 5870 and nothing after that.

[trojanfoe]

@bpasero There wasn't anything particularly special about the project. I think if you created a new Unity project, set it up to use VS Code and then attempted to edit some scripts, you would see the same issue.

I am using OSX 10.11.3 on a fairly old MBP (Late 2010).

[bpasero]

@Kane-Sendgrid thanks for trying, I guess when you changed the file you did not recompile, could that be true? We typically run gulp watch first, which will compile the project and listen for changes to incrementally compile.

[kanekv]

@bpasero [Service Library: Watcher] Do we have fsevents?: true, my coworker doesn't have problems though with the same project.

[bpasero]

@Kane-Sendgrid thanks, so this means the native (and good) file watcher is active. it is interesting that you say your coworker is not seeing issues, maybe this could lead us to the actual problem. some questions:

• does your co worker have similar hardware as you (mainly is the disk a SSD in both machines)?
• are you seeing the CPU spike NEVER going down or after a moment going down?
• is your co worker not seeing a CPU spike at all?

[kanekv]

@bpasero We have similar hardware (I have MacBook Pro 15, he has 13, same year model). I'm seeing Electron Helper process spiking in CPU and memory and then it dies and starts ramping up again. Let me wait and see how long it can go (it was going at least 5 cycles for me during ~10 minutes). My coworker doesn't see spike.

[bpasero]

@Kane-Sendgrid interesting, so you say the process increases also in memory and then actually exits and starts this process over again?

Can you give me some numbers on the workspace: how many files and folders?

I realise that we always restart the watching process when it dies so it would never end for you.

I cannot believe that your co worker is not seeing an increase in memory and CPU when opening the same folder though, does he have other settings than you? is he really opening the same folder?

[bpasero]

We found out about the issue and here is what happens:

• user opens a large folder in VS Code
• VS Code installs a watcher on the root of the folder from another process
• watcher starts to walk the folder in a way that memory increases a lot
• eventually the process dies with out of memory
• VS Code detects this and starts the watcher again because we typically never want to loose the watching information
• this goes on and on forever and simply results in constant and high CPU use

We also verified that chokidar was not falling back to polling.

The fixes for March are:

• allow the user to configure excludes from the new files.watcherExclude setting
• add node_modules to the excluded folders by default
• do not restart chokidar after 5 failing attempts

For the future, we are looking into #3998

[andradei]

I'm seeing this issue on version 1.4.0 for OS X El Capitan.

I notice this only happens after I open my project's .gitignore, the file is pretty small in size (2.5K), so this might be a different issue with the same outcome.

[bpasero]

@andradei can you check the full arguments of the process to see which of our processes are causing it?

[andradei]

@bpasero How do I do that?

[andradei]

I found out that an extension was causing this for me:

I'll leave the issue reference here in case it is helpful.

mt40/vscode-todo-parser#21

[RafalWilinski]

VSCode 1.4.0
I've also encountered this issue, I'm seeing one Code Helper instance eating 100% of one core power.

Full arguments to the process:

/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper /Applications/Visual Studio Code.app/Contents/Resources/app/out/bootstrap --type=watcherService

My settings.json:

{
      "editor.tabSize": 2,
      "compilerOptions": {
        "target": "ES6"
      },
      "files.exclude": {
            "**/.git": true,
            "**/.svn": true,
            "**/.hg": true,
            "**/.DS_Store": true,
            "node_modules": true
      }
}

Extensions I'm using:

beautify
jsx
Handlebars
ESLint (disabled for this project)
GIt History
Auto Close Tag
Color Highlight
vscode-icons
Bootstrap 3 Snippets
Javascript (ES6) code snippets
Reactjs code snippets

Files & ports opened by process

[bpasero]

@RafalWilinski does it also reproduce when running without extensions loaded:

I am very sorry to hear you are having issues with VS Code. I wonder if this issue is being caused by an installed extension. Can you try to run VS Code without extensions? From the command line, execute: code --disable-extensions and try your steps again to see if it reproduces. If you see it is an issue with the extension, please file it against the extension repository itself.

[RafalWilinski]

I've just removed all extensions and reopened project - same thing happens.

Project I'm opening: https://github.com/RafalWilinski/ember-gmail
Let me know if you need more info.

Edit: I know it's not related but I've just tried opening this project in Sublime Text and I just cannot do that. Once I click open, whole ST hangs (because it's single threaded unlike vscode?) also causing 100% CPU usage. Other projects are working fine.

Edit2: Nevermind, Both VScode and Sublime text tried to index/parse/whatever ./tmp dir full of babel noise which always ended up badly. My fault, sorry for wasting your time.

[bpasero]

@RafalWilinski so you say you have a single folder with lots of files within? what kind of folder is that? maybe we should consider adding it to the default watcher exclude setting.

[bpasero]

Btw I just setup this project and do not see a 100% CPU core (Mac OS X).

[RafalWilinski]

In my project there was a tmp folder generated by babel. Inside, there were around 20000 subfolders and tree | wc -l = 522100 files & directories overall with total weight of 1.2GB(!), it took a couple of seconds to even rm -fr /tmp it.

I don't think that tmp folder should be ignored by default. For some cases there may be some actual code written by users.

@bpasero Because repo does not have /tmp folder in it, it accumulates over the time.

[bpasero]

ok thanks, for me the folder was much smaller. you can get the CPU down by adding this folder to the watcher exclude and it would also make sense to add it to search excludes.