-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(macos) Analyzer sometimes stops responding in VSCode when mass file change events occur #45996
Comments
@aam this reminds me a lot of #40348, although there it was clear the server had crashed, but here it seems like it just stops responding (I don't know if that's because it's a different issue, or crashes behave differently on macOS). I've not been able to reproduce this myself. Is there anything @acoutts could do that might help understand what's happening (for example getting some sort of dump of the analyzer VM process that could be examined)? |
Using the same pubspec as my big app doesn't seem to break it, so it's not something inside the |
If I open that isolate's debugger from the observatory before managing to reproduce the bug, I can view the output so it seems like you have to connect to that prior to the bug happening. |
Happens to me also on intellij. What I noticed, is that If I enter the file where there is no analysis, and I change somethin (add and delete space) the analyzer recovers for that file only. I have to do it in every file, or just invalidate caches and restart. Let me know if there is something else that I can do |
Is there any chance we can bump the priority on this one? It's really painful having to frequently pause everything to stop debug sessions, restart the analyzer, and do a new build again every time I change branches or run a build. |
Seems to have trigger it once also.
|
We've just taken for granted that enabling/disabling sparse checkouts requires a restart of VSCode. I wonder if this is why. |
I have my model generated with 'flutter pub run build_runner build --delete-conflicted-outputs'. There, even that failed and needed to restart VS code entirely. |
Not sure whether VM-level logging will reveal anything useful as it might be too low-level. Perhaps enabling logging of analysis server could reveal last thing it does when it hangs? |
I observed the analysis server going into such state when its main isolate is "loading" a couple of times before. But I have always thought that it is not an issue of the Dart code, but of the VM. Even when there is a cycle in Dart code, the Observatory should continue profiling and show statistics, right? We also had (and fixed, and re-enabled null safety) flutter/flutter#81492. |
@aam there are a few logs in the Dart-Code issue linked above - the last lines logged by the analysis server instrumentation file are watcher events (they look like files the server would just ignore, though I don't know if there were further events that occurred but weren't logged/flushed to disk):
@acoutts can you still repro on versions since that change landed? |
Since that change is in the flutter engine, wouldn't that not be relevant here since the issue is with dart and affects vscode even without a debug session active (ie: change git branches)? |
I've just confirmed the issue is still happening on the latest dev release |
I've managed to reproduce this, and can now do so reliably (on my Mac at least). I'm triggering it by changing Git branches between two versions of
In another terminal, run the analysis server (it happens the same whether run from source or snapshot):
Paste this line in to start the server analyzing and wait for it to complete:
Paste this line in to verify the server is responsive (it will respond with an error):
Wait for analysis to completely finish then open http://localhost:8999/ to get Observatory for the analysis server. Now in the Git terminal window, change branch:
The server now becomes unresponsive and no longer responses to sending the dummy "foo" request from above. Reloading the Observatory window shows the Isolate "loading" and unable to access the debugger functionality for. I'll dig around in the server source a little to see if reducing/removing the code that runs in the watcher events makes any difference. |
@aam @scheglov I did some digging and found that removing this call to sdk/pkg/analysis_server/lib/src/context_manager.dart Lines 561 to 568 in 7848124
I inlined that method and stripped out code until I was left with this triggering it: if (file_paths.isAnalysisOptionsYaml(pathContext, path) ||
file_paths.isDotPackages(pathContext, path) ||
file_paths.isPackageConfigJson(pathContext, path) ||
file_paths.isPubspecYaml(pathContext, path) ||
false) {
var collection = _collection;
if (collection != null) {
for (var context in collection.contexts) {
var rootFolder = context.contextRoot.root;
changeSubscriptions.remove(rootFolder)?.cancel();
}
}
return;
} It seems like cancelling the DirectoryWatchers stream inside its handler may be causing this. I was able to repro this in a simple script: import 'dart:async';
import 'dart:io';
import 'package:watcher/watcher.dart';
late StreamSubscription<WatchEvent> sub;
main() {
final folder = Directory('/tmp/flutter_gallery');
Timer.periodic(Duration(seconds: 1), (_) => print('ping!'));
sub = DirectoryWatcher(folder.path)
.events
.listen(_handleWatchEvent, onError: _handleWatchInterruption);
}
void _handleWatchEvent(WatchEvent e) {
print(e.path);
// sub.cancel(); // Uncommenting this triggers the issue
}
void _handleWatchInterruption(e) {
print('Watcher error! $e');
} If I run this script and switch between branches, it dumps a list of all the files as they are modified and prints And the isolate looks the same in Observatory: I'm not sure whether this points to watcher or the VM, but it's probably as far as I can debug (at least without some pointers). |
Awesome investigative work @DanTup, thank you! Yeah, something is up with the way how file system watchers are set up and torn down. Let me see if I can dig deeper. |
@DanTup this is amazing. Thank you for finding this! |
Hopefully https://dart-review.googlesource.com/c/sdk/+/201442 addresses the problem |
there might be more cases where this could block: adding a new watcher seems to lead to a similar deadlock |
Confirmed that this fixes it! It's now in flutter master channel. |
… dart thread. At present start/stop requests are scheduled on RunLoop thread. This results in deadlocks since same RunLoop thread might be busy with blocking writes of file watching events, not giving a chance for Dart to read previously-written events. Reading would unblock writer. So this CL moves start/stop requests to run on Dart thread instead. Fixes #45996 TEST=run analysis_server against flutter_gallery github-backed folder, switch between branches and ensure analyze_server remains responsive Change-Id: I0464eeecf8e46ba3027fa0ed21cc323495d965c3 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/201442 Commit-Queue: Alexander Aprelev <[email protected]> Reviewed-by: Siva Annamalai <[email protected]>
I faced this issue when changing the directory name where Flutter SDK placed and setting the new path from vscode json settings. I solve this by removing the SDK path from json settings and click (cmd+shift+p) and run Flutter: Change SDK (Auto-Detect SDK Location). |
I've been dming @DanTup for a couple of weeks about this issue (first reported here: Dart-Code/Dart-Code#3295
After tons and tons of testing to narrow things down it seems like when you have a large project open and there's an event which triggers a ton of file changes at once, the analyzer stops responding in vscode and never recovers from its analyzing state.
I cannot reliably reproduce the issue, but i've narrowed down to it sometimes can occur while doing the following:
flutter clean
flutter run
flutter pub get
These seem to cause a lot of file changes and sometimes (quite often) results in the analyzer not recovering. To fix it you have to stop your debug session, restart the analyzer, and do a full build again to start over. It has been quite annoying and some others are noticing it too (cc @lukepighetti).
I tried adding the
ios
and.git
folders todart.analysisExcludedFolders
but it had no effect.@DanTup mentioned there was a similar issue in windows related to file watchers and he suspected it could be the same issue affecting macos here too.
In all cases everyone I know that has experienced the issue has been running macos. In all of my affected instances i'm running an iOs build (both simulator and physical device are the same effect). All of my affected systems have quite high specs in terms of disk speed.
My affected systems:
I created a test project here with a large number of dart files (10,000) to try and reproduce the issue:
https://github.com/acoutts/dart-crash-issue
But in testing that project alone won't break things. I have to add my (large) app to the vscode workspace and that's when the issues start. The only changes I can think of between these are my project has more packages (more pods maybe - larger iOS folder) and a huge git history (800mb+ .git folder, using LFS as well).
The text was updated successfully, but these errors were encountered: