Zombie TS-server processes

[bpasero]

• VSCode Version: 1.8 insider
• OS Version: macOS

Steps to Reproduce:

(note that I am running out of sources, did not try to reproduce from a real build)

1. open the vscode source code folder
2. run a search for "copyright"
3. replace all with "copyright2"
4. wait for all the heavy work to be done
5. ensure a ts file opens as dirty (it should automatically)
6. save all dirty buffers
7. wait for 5 seconds for the dust to settle
8. reload the window

=> at this point the activity manager shows left over TS server processes that seem to have no parent

The process in question seems to be the typings installer:

[bpasero]

Update: I think this is easy to reproduce by just reloading the window with TS files open. The typings installer seems to cause the TS server to stay alive.

[dbaeumer]

I am not able to reproduce this on Windows however Windows has a more aggressive strategy to kill processes when parent processes die.

@mjbvz can you have a look on Mac please. The way how that should work is as follows: the tsserver listen on a close event on the stream it is reading / writing to and exits if this happens. See https://github.com/Microsoft/TypeScript/blob/master/src/server/server.ts#L396

So either the streams don't close or the tsserver can't process the event since it is busy.

@bpasero the ATA process is in since quite some time. Have you seen this before.

Might be a change caused by adopting 2.1.x ?

[bpasero]

I never actually looked for this issue so I am not sure if it is new or not.

[intellix]

I'm also getting this. Not sure if it's exactly the same but towards the end of the day I'll have between 1-5 extra "Code Helper" processes, each taking around 100% CPU each.
I start to notice when my projects take AGES to build, so I look at Activity Monitor and see a load of processes hanging. Beginning of a restart my builds take ~2.5sec. Towards end of day it's more like ~8sec
Was working last night and then upon opening my laptop this morning I notice there's another process still hanging which I have to manually kill. I've no idea what to look for or how to help you guys find the issue, but I've taken screenshots of activity monitor and process dumps etc in hopes that it helps.

Ping me if you want me to do anything, cause it happens all the time to me. I'm on gitter all day every day: intellix

TypeScript: 2.0.10
VSC: 1.8.1 (probably since 1.8.0 or earlier)
Working on an angular-cli project: https://github.com/angular/angular-cli

[bpasero]

@intellix To find out more about this issue, we need to get at the process that is causing the high load. VS Code creates multiple processes, each with different tasks. Depending on your OS you can get at the full command line of the process and paste it here. On Mac, the Activity Monitor allows to find the PID of the process and from a terminal ps aux | grep <pid> reveals its arguments.

On Windows a tool like Process Explorer helps:

Once you have the information please update this issue with it. Thanks!

[intellix]

ok so it seems to be caused by this: https://github.com/angular/vscode-ng-language-service

/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper /Users/dominic/.vscode/extensions/Google.ng-template-0.0.10/node_modules/vscode-languageclient/lib/utils/electronForkStart /Users/dominic/.vscode/extensions/Google.ng-template-0.0.10/server/server.js --node-ipc

[mjbvz]

During last month's TS performance investigation, we tracked down many cases of these zombie processes to this TS file watcher bug: microsoft/TypeScript#14636 One possible workaround is to make sure that all of your jsconfig and tsconfig files specify an include configuration to limit the number of files that TypeScript scans. TS is looking into a fix with the next release

If you are still seeing either tsserver or typingsinstaller processes hanging around in the VSCode 1.11 even after you have properly setup your jsconfig or tsconfig, please open a new issue so that we can continue investigating this bug