-
Notifications
You must be signed in to change notification settings - Fork 5.1k
[mono][metadata] Replace use of mem manager lock with loader lock #91190
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
Conversation
Hash table operations under the mem manager lock could end up taking the loader lock when performing type comparison, in the case where custom modifiers needed to be loaded. Use the loader lock instead to prevent deadlocks.
We should backport to net8.0 /cc @SamMonoRT |
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
@BrzVlad @SamMonoRT @lambdageek is this ready to get backported? I think this is the most impactful failure in 8.0. |
/backport to release/8.0 |
Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/6024778897 |
Wouldn't be better to modify the hashtable equality functions so they wouldn't lock ? |
That might be difficult - I think the issue is that they indirectly trigger |
Is there a stacktrace which shows this happening ? |
|
Hash table operations under the mem manager lock could end up taking the loader lock when performing type comparison, in the case where custom modifiers needed to be loaded. Use the loader lock instead to prevent deadlocks.
Fixes #90834