Hundrets of flow processes

[anpieber]

As you can see in the following screenshot, I currently have 733 hanging flow process. if I execute the flow commands they do also hang. If I kill the server (process 30088 and 30064 in my example), all processes will be killed and a new server will respawn.

If I run the flow command dirctly in the root folder I DO NOT get those problems. I'm kind of clueless how to continue. Anybody with an idea about the problem?

About my system, the versions and configurations:

➜  ~ uname -a
Linux prime 4.13.5-1-ARCH #1 SMP PREEMPT Fri Oct 6 09:58:47 CEST 2017 x86_64 GNU/Linux

➜  ~ yaourt -Q visual-studio-code
local/visual-studio-code 1.17.1-1

Flow Language Support 0.7.2

{
    "git.confirmSync": false,
    "window.zoomLevel": 0,
    "files.autoSave": "onFocusChange",
    "flow.useNPMPackagedFlow": true,
    "javascript.validate.enable": false,
    "workbench.sideBar.location": "left",
    "eslint.autoFixOnSave": true,
    "workbench.colorTheme": "Default Light+",
    "eslint.server.trace": "messages"
  }

➜  hilda git:(dev) ✗ cat package.json| grep flow
    "babel-preset-flow": "6.23.0",
    "eslint-plugin-flowtype": "2.39.1",
    "flow-bin": "0.57.2",

Thank you very much for any idea and/or support!

[n1ru4l]

This might be the solution: #150

[quisido]

Hey, I'll second and third this. We disabled the Flow for VS Code extension, as this started happening when we upgraded to the latest version of Flow. Running Flow from command line has no problems, but the VS Code extension will max out RAM on our systems to the extent that even the Internet doesn't work for some reason. Opening Task Manager, we see Flow running an unbelievable number of times -- closing the dozens of instances will get Internet back for us. This has happened on multiple dev machines and very reliably and repeatably. Something about the extension is causing flow.exe to run an infinite number of times in the latest version of Flow. I really hope this is fixed, because I miss having inline annotations for Flow errors. But right now, it is impossible for me or my team to use this extension.

[orta]

This is a project run by volunteers, you're welcome to help improve it 👍

[quisido]

Just because I know how to use Flow doesn't mean I know how to write VS Code extensions.

Just reporting that y'all have a memory leak.

[danielkcz]

I would love to help also as this is rather annoying. Unfortunately, I am on the same page as @CharlesStover . Perhaps we can approach this more collaboratively and shoot some ideas what might be an actual culprit?

[orta]

A VS Code extension is just a node module, it's not different than most JS codebases - I'd recommend setting it up, adding a few logs and using the dev build to see if you can re-produce

[jony89]

flow version 63.1 + VSCode, kills my new mac 2.8GHz i7 16RAM with tons of processes,

can't even kill it correctly with :

flow stop

it restarts with tons of other processes again. had to do force quit from the p-list and close VSCode.

[danielkcz]

I kinda want to thank you for this issue. It forced me to switch to Typescript which I was afraid of for so long and now I am much happier. I don't want to pose as some cheap traveling salesman here, I am just an honest developer. I am sorry if I hurt someone's feelings here ;)

[jtnix]

Still a huge problem with Flow 0.82 plugin

[FDiskas]

I usually use flow stop console before quite the vscode. It stops all processes 📝
created pull request

[gamegee]

They should name it Slow not Flow..
hehe :)

[noahtallen]

I don't get a ton of processes per se, but I definitely occasionally get a few rogue Flow processes that just destroy processor space in the background. I haven't had VS Code open for several hours (still working on other stuff), but it's still doing it:

[karltaylor]

Currently have +10 flow processes running when using Flow & Visual Studio Code

node_modules/.bin/flow stop doesn't kill processes

[FDiskas]

node_modules/.bin/flow stop should be executed in project directory

[noahtallen]

@karltaylor I can get them to stop when I manually kill them from activity monitor

[karltaylor]

node_modules/.bin/flow stop should be executed in project directory

@FDiskas This is correct

If I run $ ps aux | grep flow | grep -v grep | awk '{print $2}' I would sometimes have 10/20/30 flow processes.

Then running $ kill $(ps aux | grep flow | grep -v grep | awk '{print $2}') would kill them. But 10/20/30 would come back when running flow with VS Code.

After a few reinstalls and leaving flow to do it's thing (and adding .history vscode addon) to .flow-config. It seemed to fix itself 🤷‍♂️

[jml6m]

Getting the same issue, yet flow stop doesn't work for me:

> my-proj@1.0.3 flow C:\Users\User\workspaces\my-proj
> flow "stop"

Trying to connect to server for `C:\Users\User\workspaces\my-proj`
Attempting to meanly kill server for `C:\Users\User\workspaces\my-proj`
Failed to kill server meanly for `C:\Users\User\workspaces\my-proj`

[brookemahoney]

I was having a problem with many flow processes hanging around in the Mac Activity Monitor. To fix this, I changed my flow command from flow to flow; flow stop.

For what it's worth, I use flow in a pre-commit git hook using https://www.npmjs.com/package/pre-commit

[noppa]

@jeffymahoney You can just run flow check instead and it won't leave the server hanging. But that doesn't really help with this extension, not reusing the server between checks that are made on every save (or every change) would kill the performance.

[brookemahoney]

@jeffymahoney You can just run flow check instead and it won't leave the server hanging. But that doesn't really help with this extension, not reusing the server between checks that are made on every save (or every change) would kill the performance.

Thanks, I'll give that a shot

[indolering]

Why is this closed? It's still an issue.

At the very least, you could lower the priority of the process. What about adding code that checks the number of existing Flow language servers and cap them to 3x the number of CPU cores?

On Linux, you could use CGroups to limit the CPU and memory consumption of the processes.

[noppa]

As far as I understand, this issue was about Flow processes not being terminated correctly when the extension was closed. Over time, tens or hundreds of processes would be left hanging in the background.
Do you still see that happening, @indolering? I personally haven't seen that happen in a long time (on Arch Linux, Flow 0.94.0). For my setup, Flow consistently creates about 13-20 processes per workspace and they are successfully terminated if I close VSCode. Sure, 13-20 processes is quite a lot, but AFAIK that's not something that can be controlled from this extension and should be a separate issue in the Flow repo if it's a problem.

[indolering]

@noppa I can't see how many process are running because my machine immediately locks up.

[diegolamanno]

I am having the same issue. Funny enough, I am the only one in my team that's having the issue. We all have the exact same machines using the same codebase and VSCode configuration. We moved from 0.83.0 to 0.94.0 thinking that might solve the issue but nothing changed.

I am talking my MacBook becomes unusable because I have 5-9 flow processes running. Each one of them taking between 1.4GB to 2GB of RAM. The MacBook has 16GB and 80% of it is taken by flow.

[indolering]

@noppa

For my setup, Flow consistently creates about 13-20 processes per workspace and they are successfully terminated if I close VSCode. Sure, 13-20 processes is quite a lot, but AFAIK that's not something that can be controlled from this extension and should be a separate issue in the Flow repo if it's a problem.

This code should have some impact on the number of processes:

 _getMaxWorkers(): number {
    return Math.max(os.cpus().length - 2, 1);
  }

Maybe make this configurable?

[noppa]

@indolering Huh, yeah looks like I was wrong. I agree that it could be useful to make that configurable.

Just to clarify in case my comments were misleading, I'm just a user of Flow & this extension, I haven't contributed any code in yet and can't make these decisions.

[warent]

This is happening for me as well. I have over a dozen flow processes open, altogether eating up about a gig of RAM

[Mayank1791989]

How many processes? Which os?

[georgekpc]

I faced many of flow processes and 100% CPU usage even when the editor was closed.
Fixing all flow errors in my code solved my issue.

[ArcaneEngineer]

@georgekpc That implies there are cases where the type checker gets caught in infinite loops. I think the authors need to put in some break cases with error logging if the process runs too long - that way they will find what is causing the problem, through a logged stack trace.

[phraemer]

I'm on a 12 core/24 thread machine and this is absolutely crippling it but it's not really a memory issue but probably blocking IO

Even with server.max_workers=1

I see many processes started:

[jeffal]

(Cross-posting my comment from here: amilajack/eslint-plugin-flowtype-errors#27)

I've had this issue occur when running multiple versions of flow-bin at the same time.

I recommend checking if you have a global version installed or if your repo has multiple flow-bin dependencies (monorepo), that they are all in sync across the board.

[Etheryte]

For anyone else running into this problem, in our case it was a problem with Flow running out of memory with its dependency hash table. Naturally, no error is logged about it, the server just crashes and is restarted over and over again which results in the above.

Increasing the hash table size in .flowconfig resolved the issue for us:

[options]
server.max_workers=1
sharedmemory.hash_table_pow=22