"Expected to link dart:core and dart:async first" error from AnalysisDriver._removePotentiallyAffectedLibraries #48051
Assignees
Labels
area-dart-model
For issues related to conformance to the language spec in the parser, compilers or the CLI analyzer.
P2
A bug or feature request we're likely to work on
type-bug
Incorrect behavior (everything from a crash to more subtle misbehavior)
Comments
|
Yes, I saw this before, these two happen periodically internally. I was not able to track them down so far. More data could probably be gathered in places where we load ( |
|
I'm not sure I know enough about this to be able to add more useful detail, although if it helps I did find the log from when I hit this myself. For me, the thing left in the list was |
|
hmm, the log in Dart-Code/Dart-Code#3625 also has an open and close right before this happens. I wonder if some async work in opening a file could result in it not being complete before the close is being handled? |
|
Yes, somehow this URI |
|
I don't have any ideas either. I don't know how it would reference a different
Hmm, this initially sounded odd - I wasn't modifying anything in
It seems unfortunate that hovering over a symbol inside a users own file in the editor can result in triggering this work. I wonder if it could be avoided? (it doesn't fix the underlying bug here, although it would probably significantly reduce the chance of it happening because it's unlikely We can't prevent the |
|
This came up at #48458. Some info that may or may not be relevant from that thread:
|
I am having this crash multiple times a day, doesn't matter the type of project (both in projects with and without null safety), nor the project size. Flutter doctor: [✓] Android toolchain - develop for Android devices (Android SDK version [✓] Chrome - develop for the web [✓] Linux toolchain - develop for Linux desktop [✓] Android Studio (version 2021.1) [✓] VS Code [✓] Connected device (2 available) [✓] HTTP Host Availability • No issues found! It usually happens when I have left Ctrl button pressed. |
|
I do still see this (though very infrequently) but haven't been able to reproduce it either manually or in a test. All the reports that have logs seem to contain the same thing, a So my feeling is that there could be some race when a file is opened (overlay created) and closed (overlay destroyed) in a short space of time. One thing that might reduce the chance of it happening would be to short-cut and not trigger this code when an overlay is created if it doesn't actually change the contents: In the cases that are triggering this, an SDK file is being opened, but it's content is almost certainly the same as on disk, but we still end up calling If that seems like a sensible thing to do, is (Edit: I pasted the integration test I'd been using to try and repro here in case it's useful to come back to so I don't lose it) |
Out of curiosity, is this for a file in either
I hadn't realized that
That sounds good, but I'm not sure how that plays with the watcher. We'll need to think about possible timing scenarios.
I'd be more comfortable putting the check in the code that's going to call |
In one of my repros above, the file was
I'm not sure if I understand the scenario you have in mind. The
Yeah, that makes more sense. |
|
It seems sad to try to hide an issue by adding workarounds. Ideally we need to reproduce and fix it. |
|
It sounds like it might not be too hard to reproduce now that we know some files that trigger it. Though it looks like a timing issue, probably when we ask to resolve a file in the core library before we've built the core library (and hence the type provider, etc.), and those can sometimes be tricky. |
I agree we need to track this down and fix it - although my suggestion wasn't to hide or workaround it. It seems like the issue is being triggered where we're work under the assumption that an SDK library has been modified when it has not. I think the change above may make sense regardless of this issue (for performance reasons) - especially given VS Code triggers opening+closing on a bunch of files the user doesn't even open when it just wants to show previews in tooltips etc.? |
|
How do you run the test? To which class do you add this method? Yes, it might be some timing issue. It looks to me that it is not so easy to check if a change should have any effect. We want to know if the content is different than what is in |
|
I was running the test in the LSP diagnostic test class here: I tried a bunch of different things (with/without
In what situations might each driver not have the same content? I thought we could read the file once (through |
|
Race conditions are hard :-) Well, you are right, in the server the content of a file must be the same for all drivers. So, this might work, at least I cannot think out why not. |
copybara-service bot
pushed a commit
that referenced
this issue
Jul 20, 2022
…tent matches previous content- May prevent #48051 from occurring since we will no longer call driver.changeFile() for SDK libraries being opened, although it does not resolve the underlying issue. Change-Id: I5ca53a04842348a584ccc824aaf90ba7f230c002 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251980 Commit-Queue: Brian Wilkerson <[email protected]> Reviewed-by: Brian Wilkerson <[email protected]> Reviewed-by: Konstantin Shcheglov <[email protected]>
|
If that helps - I've got when navigating in vs code into |
|
I am also getting a similar error as @emakar, several times a day. and they also usually occur when navigating to an area of the code, or saving a file. full log: Details |
|
I made a change in 0add39a which I hoped would reduce the chance of this (it always seemed to be related to overlays for SDK files which are rarely modified, so may not need overlays). It's not clear that worked, but it looks like when a file is closed in VS Code we still unconditionally call |
|
I also seem to encounter this when navigating to definitions while working on Flutter. Here are some more logs, in case it's of any use: log 1extension v3.71.20230801 log 2Unknown VS code extensions/dart SDK version (somewhat recent) log 3Unknown VSCode extension/dart version. Somewhat recent. |
copybara-service bot
pushed a commit
that referenced
this issue
Mar 27, 2024
…ework files This fixes the check to determine whether a file is Flutter to handle things in Flutter itself. It also improves the optimization for not setting overlays when they're the same as on-disk to handle files from dependencies (not only those that are explicitly analyzed) which might help avoid #48051 (comment) more (it was the original intention, but perhaps wasn't working as well as I'd believed). Fixes Dart-Code/Dart-Code#5045 Change-Id: Ibd04ebeb10e9a1e749f2b44d4053f9b467554f4f Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/360042 Reviewed-by: Brian Wilkerson <[email protected]> Reviewed-by: Konstantin Shcheglov <[email protected]> Commit-Queue: Brian Wilkerson <[email protected]>
srawlins
added
the
type-bug
|
I am getting this crash ~50 times a day |
johnniwinther
added
area-dart-model
|
@stereotype441 thank you! I don't see this that often anymore, but I did see it a handful of times in the last week or so (and was wondering if it'd gotten worse).
FWIW, when the next version of LSP releases, there's an update to the VS Code LSP client that should finally allow us to avoid these phantom open/closes when VS Code is just reading files contents (for example when hovering while holding Ctrl and it's trying to show a preview of the code in the hover). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This error has been reported a few times via the VS Code extension. I'm not able to reproduce it, but I did see it once after working for a few hours and could not reproduce.
@scheglov I see the error comes from
sdk/pkg/analyzer/lib/src/summary2/linked_element_factory.dart
Line 224 in a2fd0da
Perhaps a coincidence, but when I saw this I was working on the analysis server codebase, and the user from the last comment above also seems to have some analyzer packages in the list. There are some other errors also reported in the last issue above, but I'm not sure if they're the same cause - for example:
The text was updated successfully, but these errors were encountered: