analysis server consumes significant memory when VS Code restores a dirty file buffer for a project that no longer exists #4280
Comments
|
in /tmp/tmp.xxxx( |
|
Can you run |
DanTup
added
the
awaiting info
|
I can explain the recurrence steps of this problem hand in hand:
|
Reply: information from
|
I also repeated this question when I turned off all plug-ins and opened only one Dart plug-in. |
|
@zinface thanks for the detailed steps. Unfortunately I haven't been able to reproduce it (although I'm on macOS, I don't know if that's a factor). Is it possible you can set the analyzer instrumentation log in your VS Code User Settings: https://dartcode.org/docs/logging/#analyzer-instrumentation "dart.analyzerInstrumentationLogFile": "/path/to/log.txt"And then reproduce the issue, and see whether this log file is being written to as the memory usage is growing? You can attach the log or email it to me at logs@dartcode.org if it's not too big (but please reproduce this with a small sample app, because the log may contain parts of source code from the open files). Thanks! |
I have e-mailed the information you mentioned, along with about 2 minutes of screenshot files (reproducing the problem). |
|
@zinface thank you for the detailed video and logs! I think I see what's going on. When VS Code is opened with that unsaved file, the server tries to create a watcher for it - however the file does not exist on disk and this causes an error: This server interprets this error as something it can recover from, so it tries again. And it keeps retrying repeatedly forever. I'm not certain why the memory usage climbs so high, but now I understand the cause I might have better luck reproducing it so I can work on a fix. Thanks! |
DanTup
added
is bug
in lsp/analysis server
DanTup
changed the title
|
@zinface sorry for the delay. I'm working in this now but struggling to reproduce (even on Linux). The attachment links in you email have now expired - do you still have a copy you can re-send to me to logs@dartcode.org so I can understand what's different between my setup and yours? Thanks! |
I just saw the email now. Of course, it's already the weekend. I have re-sent the content I prepared last time. |
|
In addition, I have prepared a shorter video to provide a clearer review process. |
|
@zinface thank you - I got the files and they are attached to the email this time, so there is no danger of them expiring :) I'm out of the office for a little over Christmas, but I will try to get to the bottom of this in the new year. Thanks! |
|
Sorry for the delay. I've been able to reproduce this in an Ubuntu VM. I'm not sure exactly what's going on yet, but will do some digging. For my future reference, here's a log file that has some additional logging from running the server from source in the VM. |
|
Ok, I have a better idea of what's happening now. In the log there are two sets of errors alternating: The first error ("Temporary watcher error") is the one we're handling while trying to build the context roots. We will try up to 5 times before giving up. The second error is code that tries to handle errors generally and triggers a context rebuild. It's this one that's causing the rebuilds to occur in a loop, not the original "temporary watcher" one (but because it triggers a rebuild, it causes that code to run again, and the error to be logged). I think there may be a difference in how these errors occur on Linux versus other platforms which is why it's only seen here, although it seems like we should detect if we get into a situation where we're endlessly trying to rebuild contexts (they're likely failing for a reason that isn't going to change if we try again). Two thoughts:
|
|
(@bwilkerson @scheglov FYI.. I think I have a fix for this, but some background for when you get the review..) I have a very easy way to reproduce what is essentially the same issue (it only occurs on Linux - there are some differences in how this kind of error is raised across platforms, I think it's been discussed before although I can't find the discussion):
You'll see the log file file up as we infinitely try to rebuild the analysis roots and consume a lot of resources. Although setting an analysis root to a non-existing directory is unlikely (though suspect deleting a valid root while the server is running will do the same), the original case here is where VS Code restores an unsaved file in a deleted directory at startup (for ex you had an open dirty file in The reason this occurs is that creating a watcher on a folder that doesn't exist emits an error on the stream (on Linux) and triggers this code that wants to restart (because a watcher error means we can't trust our state of the world): Rebuilding doesn't help because the same error will occur again, and we'll just sit in a loop doing this as fast as possible. My proposed fix is to skip that rebuild |
|
This fix seems to work in my VM: https://dart-review.googlesource.com/c/sdk/+/284660 |
…tFound errors Fixes Dart-Code/Dart-Code#4280. Change-Id: I8f36672dfd5fcca2e4be87408d385219b0a81d9c Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284660 Reviewed-by: Brian Wilkerson <brianwilkerson@google.com> Reviewed-by: Konstantin Shcheglov <scheglov@google.com> Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
|
This is fixed by dart-lang/sdk@e231f12. The change is in the Dart SDK, so will ship in a future Dart/Flutter release rather than a Dart-Code update. |
DanTup
added
the
relies on sdk changes
Uh oh!
There was an error while loading. Please reload this page.
i open my computer, and vscode , in 3 minutes , have one nosave dart code in editor(old). so , my memory always been rising.
i have a picture!
After a while:
The text was updated successfully, but these errors were encountered: