[release/9.0-staging] Moved a static field initialization from Thread to ProcessorIdCache #114273
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.
Backport of #114227 to release/9.0-staging
Fixes: #113949
/cc @jkotas @VSadov
Customer Impact
A stress issue that under certain conditions may result in a circular dependency between contending/waiting on a Lock and performing static field initialization in
System.Threading.Thread
.The result is a stack overflow crash.
The issue was reported by internal team after examining WER crash buckets.
Regression
This is a result of two features -
System.Thread
Lock
implementation with implicit assumption on NativeAOT that waiting on a lock will not run static constructors.The root cause is not new, but it is a stress bug that is relatively difficult to observe and also requires an uncommon activation pattern for NativeAOT - dynamic library mode vs. more common regular .exe.
Testing
Ordinary unit tests. Examined that
System.Threading.Thread
no longer has a.cctor
Risk
Very low risk. The fix is basically moving one private static field to a different type.