Repository navigation
Code Helper is orphaning Dart processes that dominate cpu #5084
Description
Describe the bug
I noticed that I had 8 stray dart processes on my computer that were occupying 100% of the CPU. I killed them then noticed the next day that I had a dart process dominating one of my cores again. I noticed the parent process was "Code Helper" so I closed all my apps, including vscode and the process did not disappear but was now being reported as having no parent.
screenshots
while vscode is open
after vscode is closed
info
- Operating System and version: MacOS 14.4.1
- VS Code version: 1.88.1
- Dart extension version: ?
- Dart/Flutter SDK version:
Flutter version 3.22.0-15.0.pre.Dart version 3.5.0 (build 3.5.0-84.0.dev) - Target device (if the issue relates to Flutter debugging): na
Activity
DanTup commentedon Apr 29, 2024
Are you able to reproduce this? From the screenshots this looks like the analysis server. It should be terminated when the extension shuts down, but it seems to be using 100% CPU and I wonder whether that's preventing it from closing. It's normal to use a lot of CPU when it's busy, but ofcourse shouldn't all the time.
If you can repro, does this happen for all projects, or only when you open a specific project? If only a specific repo, could you try enabling the instrumentation log and see whether it's writing anything when it's in this state?
gaaclarke commentedon Apr 29, 2024
Yep, I can reproduce it easily. All I have to do is open the flutter engine repo in vscode, then close it. I don't even open any dart files. It seems to happen 100% of the time.
DanTup commentedon May 9, 2024
I haven't been able to reproduce this on Windows or macOS, however I don't know if I have the engine repo set up exactly the same as you (I followed the instructions on https://github.com/flutter/flutter/wiki/Setting-up-the-Engine-development-environment to include the third party deps) or exactly which folder you're opening, or how long you've leaving it before closing VS Code. I do see the
dartprocess live for 5-10s after I close VS Code, but it always seems to disappear.I can see from the code that we never directly
kill()the process we start for the analyzer, and rely on it closing when the streams are closed by the LSP client. If the server is busy (which it is for a short while when starting up), that might not be immediately.I've added code that when we dispose the LSP client will kill the process (send
sigterm) after 100ms. This might improve things, but you'd have to test it. I've published in a pre-release version today which you can switch to with this button in VS Code:The version that includes the fix is
v3.89.20240509(the last component is todays date inYYYYMMDDformat) - it might take 20-30 mins to show up from when I posted this message.gaaclarke commentedon May 9, 2024
The surprising thing to me is that you are allowed to get an orphaned process. The default setting should be that killing a parent process kills the children processes. I suspect there may be a setting when forking the child process that we have wrong that allows child processes to get orphaned in the first place.
DanTup commentedon May 9, 2024
Me too, but I'm not familiar with who is usually doing the clean-up of processes like that. The code that spawns the process doesn't do much:
The docs are here and as far as I can tell, we'd need to pass
detached: trueto specifically have that behaviour.Are you able to test the changes to see if it helps? If not, are you able to leave a process around for a while to see if it does actually close? (for me it only took 5-10s but I don't know if this might also depend a little on exactly what the server was doing at the time it closed).
Also - are you able to get the full command line (from
ps?). I wonder ifdartdevis spawning the analysis server snapshot in another process (in which case there might be an additional layer of processes).Edit: It does not add another process, it spawns the snapshot in an isolate.
gaaclarke commentedon May 9, 2024
I just verified that
v3.89.20240509does fix the issue for me =)It's weird. It's probably related to the fact the process is in a bad state taking up 100% of a core. When I have the engine open I'm not even editing dart files, so running analysis is pointless. Maybe that's related.
Anyway, thanks so much Danny (I'll let you close the issue, I'm not sure how you want to do your bookkeeping for things on prerelease).
DanTup commentedon May 9, 2024
Glad to hear it fixes it, though it is puzzling. Out of interest, if you don't close VS Code, does the process forever sit at 100%? If so, it'd be nice to track that down and fix it too (in the first instance I would try enabling the instrumentation log to see if it has an indication of what's happening). We can open a new issue for that so the "fix" for this one can be tracked from this issue in the next release notes.
Thanks!
MickeyMouse623 commentedon Jul 18, 2024
DanTup commentedon Jul 29, 2024
@MickeyMouse623 please file a new issue for this. I see you have "41k" in your source control tab - have you opened a very large folder? The server will be busy while it tries to analyze whichever folder(s) you have open in the workspace.