-
Notifications
You must be signed in to change notification settings - Fork 373
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
Possible parallel workload resolver use #7946
Comments
This started showing up a lot more in validation for .NET SDK 8.0.300. See dotnet/aspire#4145 I was able to debug it, and it looks like the issue is here: templating/src/Microsoft.TemplateEngine.Edge/Settings/TemplatePackageManager.cs Lines 351 to 363 in a78c4f5
That code is scanning each template package in a separate parallel task. That leads to each template being instantiated in parallel, and when there are workload installation constraints the constraints get created in parallel, thus getting the list of installed workloads in parallel, which results to parallel calls to the workload resolver, which is not thread-safe. The workload resolver checks to see whether the manifests have been initialized, and if not, then it gets the manifests, adds them to the internal structures that hold them, and then sets the initialized flag to true. Here's that code: https://github.com/dotnet/sdk/blob/4d3cca6fa5437395a0bc984a809c1d5c12c18a26/src/Resolvers/Microsoft.NET.Sdk.WorkloadManifestReader/WorkloadResolver.cs#L87-L95 When multiple threads run this code at once, it's possible for both of them to see that the manifests haven't been initialized, and then for both threads to try to load the manifests, resulting in an error when one thread tries to add a manifest that has already been added by the other thread. The workload resolver was never intended to be thread-safe, and writing thread-safe code can be difficult. So probably we need to find a way for the template engine to not call the workload resolver code in parallel. |
In case they help, here are some stack traces of the code that ends up accessing the workload resolver in parallel:
|
Because it's buried in the linked issue, here's what the failure would actually look like when you tried to create a project using a template that used the workload constraint:
|
We are hitting this also when executing some of our template tests on dotnet/maui |
Product
dotnet CLI (dotnet new)
Describe The Bug
It seems like there may be some parallel calls to the same workload resolver after it's initialized but before any (serialized) access calls (version or manifests), and it means that we follow the lazy process for computing our manifests multiple times, leading to errors. This should not happen in the first place because the workload resolver should only ever be used from one thread.
One example of this was dotnet/installer#19222
A partial solution is dotnet/sdk#40485, but that doesn't get at the root cause of this instance. We currently believe that root cause is somewhere here.
To Reproduce
See dotnet/installer#19222
dotnet Info
output
Visual Studio Version
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: