-
Notifications
You must be signed in to change notification settings - Fork 4k
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
BatchFixAllProvider crashes with "An element with the same key but a different value already exists" #57660
Comments
We are crashing here: roslyn/src/Workspaces/Core/Portable/Workspace/Solution/SolutionState.CompilationTracker.cs Line 882 in c7521c9
|
Hmm, @jnm2 do you know what type of project this was? I know we had some bugs if we got the same generator added twice, but not sure if this would manifest here precisely. I'd assume that if that was happening this wouldn't have worked after restart though... |
So I'm not able to reproduce by a naive test, but look at telemetry it does appear there's a number of hits with this same stack, including 17.1 too so it's not something we've fixed yet. I've opened https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1463535 as an internal bug which links up with our telemetry systems so we can get more info on it. |
We did get a telemetry report with an attached crash dump. The GeneratorDriver's list of generators has a duplicate generator; we have two instances of MvvmGen.SourceGenerators's MvvmGen.ViewModelGenerator loaded and added to the GeneratorDriver at once. Oddly, it appears to be two separate instances of the same generator object, i.e. .GetType() on the two generators will give the same result and are loaded from the same assembly. That seems hard to have happen, as AnalyzerFileReference tries to cache the same object; my hunch is we must have removed and readded a reference and there's a bug where the first removal didn't work (due to some sort of mismatch with the object identities), and a later re-addition added a second copy. In any case, this doesn't appear to be a duplicate of #56619 which I was hoping it might be, or at least at the point of the fault we no longer have a duplicate in the main Project.AnalyzerReferences list. @jnm2: when you said you added global usings, do you recall if you did that by editing a source file, or editing the project file? I recognize I'm asking you to remember a subtle detail from months ago, but if you think it was a project file edit that'd make sense. |
The crash was in our OOP process which also makes me think it could have been fallout from #58990, but we're still seeing hits for 17.2 so that doesn't explain everything. |
@jasonmalinowski It for sure was by editing the project file. It's easy to remember because I haven't written a global using in a source file ever. |
We've seen a few places in the wild where a customer ends up with a generator installed twice into their project. This was causing an issue with how we generate DocumentIds for generated documents: we compute that as a stable hash over some pieces of information so that way we geneate consistent IDs in different processes, and a generated file that disappears due to an edit and comes back can also have the same ID. The hashing algorithm for a DocumentId included the generator's type name and the generator's assembly name, but if you have two generators with the same assembly name we'd collide. This could happen if you have two different generators with the same name, or your project file is messed up and causing a generator to be added from two different paths at once. This latter case isn't a scenario we support, but this change at least ensures Roslyn won't be throwing exceptions which ends up requiring investigation. Related to dotnet#56619, but doesn't entirely close it, a duplicate generator producing duplicate files will still be confusing. This may also address dotnet#57660 but the belief is there's a race condition there too, as the dumps I've seen don't show duplicate references in the project.
This should be fixed by #65039. |
Version Used: 17.0.0
Got this after trying to invoking "remove unnecessary usings" for a whole solution after adding global usings. VS froze for a while, then showed this (it opened at this position and didn't move at all) and remained frozen for a long time:
Then the gold bar appeared saying that BatchFixAllProvider encountered an error:
Restarting VS unblocked this operation.
The text was updated successfully, but these errors were encountered: