Avoid clearing thread local handles for already unloaded LoaderAllocator #102797
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…collectible LoaderAllocators
Contributor
Author
|
@jkotas @davidwrighton checks are green for this PR |
Contributor
|
Tagging subscribers to this area: @mangod9 |
Member
|
/azp run runtime-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Member
|
/backport to release/8.0-staging |
Contributor
|
Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/9293876461 |
Contributor
|
@jkotas backporting to release/8.0-staging failed, the patch most likely resulted in conflicts: $ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Ensure LoaderAllocator can't be collected while we clean handles on collectible LoaderAllocators
Using index info to reconstruct a base tree...
M src/coreclr/vm/threadstatics.cpp
Falling back to patching base and 3-way merge...
Auto-merging src/coreclr/vm/threadstatics.cpp
CONFLICT (content): Merge conflict in src/coreclr/vm/threadstatics.cpp
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Ensure LoaderAllocator can't be collected while we clean handles on collectible LoaderAllocators
Error: The process '/usr/bin/git' failed with exit code 128Please backport manually! |
Contributor
|
@jkotas an error occurred while backporting to release/8.0-staging, please check the run log for details! Error: git am failed, most likely due to a merge conflict. |
Member
|
@alexey-zakharov If you would like to see this backported to .NET 8, could you please submit a PR against release/8.0-staging branch with the merge conflicts resolved? |
Contributor
Author
Ruihan-Yin
pushed a commit
to Ruihan-Yin/runtime
that referenced
this pull request
May 30, 2024
…collectible LoaderAllocators (dotnet#102797)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation:
Fix crash in
ThreadLocalBlock::FreeTLMcode on thread exit which happens during Assembly unloading when Assembly contains a class with aThreadStaticvariable.This is a new iteration of #99998 which caused issues on CI.
Details:
There seem to be a race condition between LoaderAllocator cleanup during garbage collection and thread locals cleanup on thread exit. Racing stacks are the following:
ALC/LoaderAllocator cleanup
Thread exit with threadlocal cleanup
with an exception which is thrown with the following details:
loaderAllocatorvalue from theLOADERALLOCATORREF loaderAllocator = (LOADERALLOCATORREF)ObjectFromHandle(m_hLoaderAllocatorObjectHandle);call is NULL which makes sense, because finalizer thread just disposed data for some of the same LoaderAllocator assemblies.Note: enabling
COR_PRF_MONITOR_MODULE_LOADSCLR profiler flag increases chances for the race condition as it slows down a bit complete loader destruction.Changes:
I've looked at the following options as a solution to the problem:
loaderAllocatorBased on the discussion the acceptable solution would be to: