Repository navigation
Dart/Flutter processes left orphaned after IDE was closed #5155
Description
Describe the bug
Dart daemon was left hanging when IDE was closed.
To Reproduce
Steps to reproduce the behavior:
- In the terminal, I ran
flutter build appbundle. - While it was loading, I started a debug session of my Flutter app.
- Building completed from the terminal.
- After waiting longer than usual, "Running gradle assemble debug" message would not leave and at the debug console it got stuck with "Launching lib\main.dart on PHONE in debug mode..." even when the app on my phone had already started and I was able to use it completely fine.
- I tried to terminate the debug session with multiple clicks to the stop button, no use because of some bug.
- Closed the IDE instead.
- Opened Task Manager and saw that
dart.exe daemonwas still running.
Expected behavior
No dart.exe left running.
Please complete the following information:
Workspace Environment
Dart Code extension: 3.90.0
Flutter extension: 3.91.20240529 (activated)
App: Visual Studio Code
App Host: desktop
Version: win 1.90.2
Workspace type: Flutter (LSP)
Dart (3.4.3): C:\Users\user\.puro\shared\caches\edd8546116457bdf1c5bdfb13ecb9463d2bb5ed4\dart-sdk
Flutter (3.22.2): C:\Users\user\.puro\envs\stable\flutter (SM G780F (android-arm64/android))
Output from 'dart info'
C:\Users\user\.puro\shared\caches\edd8546116457bdf1c5bdfb13ecb9463d2bb5ed4\dart-sdk\bin\dart.exe info
If providing this information as part of reporting a bug, please review the information
below to ensure it only contains things you're comfortable posting publicly.
General info
- Dart 3.4.3 (stable) (Tue Jun 4 19:51:39 2024 +0000) on "windows_x64"
- on windows / "Windows 10 Pro" 10.0 (Build 22631)
- locale is pt-BR
Process info
| Memory | CPU | Elapsed time | Command line |
|---|---|---|---|
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe |
Output from 'flutter doctor'
C:\Users\user\.puro\envs\stable\flutter\bin\flutter.bat doctor -v
[√] Flutter (Channel stable, 3.22.2, on Microsoft Windows [Version 10.0.22631.3737], locale pt-BR)
• Flutter version 3.22.2 on channel stable at C:\Users\user\.puro\envs\stable\flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision 761747bfc5 (3 weeks ago), 2024-06-05 22:15:13 +0200
• Engine revision edd8546116
• Dart version 3.4.3
• DevTools version 2.34.3
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
• Android SDK at C:\Users\user\AppData\Local\Android\sdk
• Platform android-34, build-tools 34.0.0
• Java binary at: C:\Users\user\AppData\Local\Programs\Android Studio\jbr\bin\java
• Java version OpenJDK Runtime Environment (build 17.0.10+0--11609105)
• All Android licenses accepted.
[√] Chrome - develop for the web
• Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe
[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.4.5)
• Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
• Visual Studio Community 2022 version 17.4.33403.182
• Windows 10 SDK version 10.0.19041.0
[√] Android Studio (version 2024.1)
• Android Studio at C:\Users\user\AppData\Local\Programs\Android Studio
• Flutter plugin can be installed from:
https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 17.0.10+0--11609105)
[√] VS Code (version 1.90.2)
• VS Code at C:\Users\user\AppData\Local\Programs\Microsoft VS Code
• Flutter extension version 3.86.0
[√] VS Code (version 1.88.0-insider)
• VS Code at C:\Users\user\AppData\Local\Programs\Microsoft VS Code Insiders
• Flutter extension version 3.64.0
[√] Connected device (4 available)
• SM G780F (mobile) • 192.168.200.50:45967 • android-arm64 • Android 13 (API 33)
• Windows (desktop) • windows • windows-x64 • Microsoft Windows [Version 10.0.22631.3737]
• Chrome (web) • chrome • web-javascript • Google Chrome 126.0.6478.115
• Edge (web) • edge • web-javascript • Microsoft Edge 125.0.2535.85
! Device 192.168.200.50:37835 is offline.
[√] Network resources
• All expected network resources are available.
• No issues found!
Aditional info
Not completely sure, but I've seen a similar behaviour with a dart.exe (not sure it was the daemon) left hanging after the IDE got closed. Most of the time I saw this when opening two different Dart projects in two different instances of VSCode.
I was advised in Discord to enable the log for the daemon (and others) in VSCode. Will do and update this issue if that happens again.
Maybe it has something to do with concurrent analysers or something along these lines?
Activity
DanTup commentedon Jun 26, 2024
In some quick testing, I wasn't able to reproduce this. I tried various combinations of terminating VS Code with and without debug sessions running.
I'm going to review all of the dispose paths for this though to ensure we're not disposing anything in an async loop where one process shutting down slowly might delay another (because there's probably a limit to how long VS Code will wait for us to shut things down before just terminating the extension host).
Please let me know if you see this again (and ideally, check the log to see if there's anything interesting in there).
DanTup commentedon Jun 26, 2024
We're not - it looks like there is a clear sync path (and all other disposables have try/catch around them) to ensure the tooling daemon is terminated when VS Code disposes the
vscode.ExtensionContext.I wonder if maybe the extension host crashed or became unresponsive (which might also explain why the Stop button on the debug toolbar stopped working). It might be difficult to track this down without a good way to repro.
FMorschel commentedon Jun 26, 2024
One thing I can think of that is different is me using
puroas we discussed. I know that the project has been set to use stable and my flutter keyword in path is set to be the same but maybe something is going on between calling it withpuro flutterand onlyflutter? I'll take a look as soon as possible and let you know what I find here.FMorschel commentedon Jun 27, 2024
Still haven't tested anything related to the above comment but it did happen again with lots of log files now, just this time the same daemon was left hanging with the two instances opened.
One of them was already in debug, the other was simply opened to edit some files (but no debug session or anything). Once the first instance was down and needed to restart the debug session and connection to the device, the same behaviour happened as described above from point 4 forward.
Here are the logs
DanTup commentedon Jun 27, 2024
@FMorschel thanks - unfortunately there's nothing that helpful in the daemon log. Could you try enabling the general extension log (
dart.extensionLogFile)?Btw, some of the files you attached above are from the analyzer and may includes parts of code from your open files - if there might be anything sensitive in them you should delete them (if GH won't let you remove them, I believe I can delete the comment).
FMorschel commentedon Jun 27, 2024
Alright. Happened again. Two instances opened, only one running.
Now three hanging daemons and one
dart runthat was stopped. After closing all VSCodes, and waiting a bit, thedart runinstance vanished by itself.Also, one of the hanging daemons was using like 30% of the CPU.
Here are the new logs (all from a different project than the first logs)
Add some additional logging to help track down service shutdowns
DanTup commentedon Jul 3, 2024
Thanks - unfortunately there's nothing useful there. I've pushed a new pre-release of the Dart extension (v3.93.20240703) which has some additional logging when services are shutting down. It would be useful to see the tooling daemon log with this change, to see whether we're actually trying to shut the process down.
I don't think Puro is the issue here, but it would be useful to know what the target of the symlink at
C:\Users\felip_0vh5fa6\.puro\shared\caches\edd8546116457bdf1c5bdfb13ecb9463d2bb5ed4\dart-sdk\bin\dart.exeis.Thanks!
FMorschel commentedon Jul 5, 2024
The full cli for the dart.exe that hangs (there is no easy way to copy the cli so maybe something is written wrong, but I did try my best):
Your question above: stable/default.
See this log file I made with
dir /AL /S . > log.txtatC:\Users\felip_0vh5fa6\.puro\envs: log.txtLogs:
DanTup commentedon Jul 8, 2024
Ah, turns out this is the Flutted device daemon, not the Dart Tooling Daemon. I'd been looking in the wrong log :)
So the log above for flutter_daemon includes this:
"terminating process 165568" looks like it's sending a signal to terminate the main daemon process (we terminate this directly because terminating just the
.batwrapper might not terminate the real executable running inside it).This makes me wonder if a) the terminate did not work, or b) this log file did not match the process that was hanging around (for example it was from a previous VS Code session).
Is it possible you can try to reproduce with just a single instance of VS Code, and then verify the PID of the process that is left running versus the one that shows up in flutter_daemon log?
Thanks!
[-]Dart daemon left hanging when IDE was closed [/-][+]Flutter device daemon left hanging when IDE was closed [/+]FMorschel commentedon Jul 11, 2024
Now I got the same cli twice with PIDs 118136 and 91212 left hanging:
Also, after I closed vsCode I had a third
dart.exerunning with an even larger cli that closed itself before I could send here what it was.Logs
I had some trouble to send here the InstrumentationLog2, so if you need it, please ask that I'll try and send it again. Or even the analyzer. I have a backup from this day jic.
DanTup commentedon Jul 11, 2024
hmm, in the flutter_daemon.txt you sent it has:
This is the PID you mention was left running. The end of the log file does not contain anything suggesting we attempted to terminate the process, the last line is:
So it seems like either VS Code didn't ask us to shut down (did not call our
deactivate), or it did and we for some reason did not get that signal to the other services.I'm going to add some more logging in the extensions
deactivatewhich should confirm which is the case.2 remaining items
DanTup commentedon Jul 11, 2024
Ah, interestingly I saw a weird error in your logs:
I wonder if this is related - maybe it's something like microsoft/vscode#196948 (comment)? I wonder if when this issue occurs (which can prevent stopping debug sessions), the extension host is broken and VS Code doesn't correctly (or can't) send the shutdown messages.
In any case, I've pushed a new pre-release version (v3.93.20240711) that has some additional logging. The extension log and flutter_daemon log the next time you see this might help understand more.
The pre-release might take 15-20 mins to show up.
FMorschel commentedon Jul 15, 2024
Just a little update.
Today this happened again with another project. Although I had not yet set the log for any project with #5154 (which I did now), I did manage to take a screenshot of the other
dart.exethat was left hanging but got closed last time.As I told you before, this is the other
dart.exethat was left hanging but finished itself (or got finished) before I could write it down here.This time I simply opened the project and changed the debug configuration for the profile configuration in the launch options, after some time passed, my project was already running on my device but no connection to the debug console.
I wonder if maybe there is a problem here (with this linking) and this is why sometimes it leaves some flutter daemons hanging.
Anyway, as I said before, small update. Whenever this happens again with any project I'll now be able to give you the logs.
Edit
Just a few more things so they are explicit here:
FMorschel commentedon Jul 16, 2024
Here are the latest two instances it happened:
Project 1
Project 2
I also had a third instance where it happened but unfortunately, I reopened vsCode before making a backup of the log files by mistake.
One thing I did, in that case, was to take screenshots of all hanging CLIs. One I noticed that was different was
dartaotruntime.exewhich got closed when I closed the flutter daemon.Here is its full (I think, not sure because It was really long) CLI:
DanTup commentedon Jul 17, 2024
So this one looks different. This is
flutter run. This is a process that could be orphaned if VS Code doesn't let us gracefully shut down. This could certainly be caused by the "Invalid debug adapter"-style issues noted above (it can also be caused by clicking the Stop button on the debug toolbar a second time if it didn't shut down gracefully fast enough).The DAP log could be useful for that kind of issue, although if communication with the extension host is broken it's possible it would be incomplete.
Both the daemon and extension log files here do not show any record of being shut down. This makes me think something is going wrong and VS Code is just terminating the extension host without calling
deactivate. It's not clear to me why this would happen... one possibility is that something is severely broken (VS Code is failing to communicate with the extension host), another is that an extension (possibly us, possibly another) is blocking the single thread (for example stuck in an endless loop or just doing expensive sync work).One thing that might be useful, is running the Developer: Open Extensions Log command in VS Code, which will open a folder something like:
C:\Users\danny\AppData\Roaming\Code\logs\20240717T145824\window1\exthost
This path contains a folder with a timestamp for when the session was started. If you find the one that corresponds with the session that we think shut down uncleanly (maybe around
Tue Jul 16 2024 [07:47:04 GMT-0300 (Horário Padrão de Brasília)]for the example above), then thewindow1\exthost\exthost.logfile might have helpful logs. A clean session of mine ends like:It'd be interesting to know if this matches yours (in particularly, whether it's an exit code of 0).
FMorschel commentedon Jul 17, 2024
This time I had two vsCode instances opened and I got three
dart.exe(oneflutter runand twoflutter daemons) and onedartaotruntime.exe:Flutter daemon 1: 49812
Flutter daemon 2: 42828
Flutter run: 71396
Dartaotruntime: 71096
This time, after a while, both
flutter runanddartaotruntimeclosed themselves with no need for me to do anything.Here are the logs for both projects that were opened:
Project 1 (the one I could not terminate even when the app was running on my device already but had no response on vsCode - this instance was another flutter project before, I did
CTRL+K+CTRL+O)Project 2 (the project I was already working on previously and intended to go back soon)
Here is the zip for the log folder you asked.
Unfortunatelly I did not had the logs for yesterday morning anymore. Hope this ones help.
DanTup commentedon Jul 23, 2024
Sorry for the delay. I think this log shows the problem:
It seems that the first thing we do during shutdown is to call
void vs.commands.executeCommand("setContext", ...)and that appears to be throwing exceptions. If those are synchronous (I can't tell from the stack trace), I think that would cause the rest of the shutdown to be skipped.I'm not sure why this isn't happening for me or affecting a large number of people - perhaps there is a timing aspect to it (the extension host is shared, so maybe you have other extensions that are delaying Dart-Code's deactivate call just enough that these calls fail, but for others/me they do not).
I will make this code more resilient and push a new pre-release shortly for you to try out.
[-]Flutter device daemon left hanging when IDE was closed [/-][+]Dart/Flutter processes left orphaned after IDE was closed [/+]Improve deactivate method to ensure more cleanup fires when exception…
DanTup commentedon Jul 23, 2024
@FMorschel I've published an updated pre-release of the extension (v3.93.20240723). Could you try updating to that (note there was a pre-release yesterday with a similar version number ending in 22, you need 23), close all VS Code instances and terminate any orphaned processes (if any) from the old version, and then let me know if the issue is resolved?
Thanks!
FMorschel commentedon Jul 23, 2024
Not even showing (the version ending in 22). Will do that and let you know.
DanTup commentedon Jul 23, 2024
Ugh, apparently I typo'd the version number yesterday and published with 2022 where the year should be (it's the 6th one down in your screenshot), so it was considered older. Doh!
But anyway, the latest one is what you want now anyway. Thanks!
FMorschel commentedon Jul 30, 2024
As we've talked over on Discord, this issue doesn't appear to be happening anymore! I'll go ahead and close this. If this ever becomes a problem in the future and someone finds this issue, please file a new one (as I will) and feel free to reference this as your starting point for others to see anything related as well.