-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[release/9.0-staging] Use FLS detach as thread termination notification on windows. #110629
base: release/9.0-staging
Are you sure you want to change the base?
[release/9.0-staging] Use FLS detach as thread termination notification on windows. #110629
Conversation
Tagging subscribers to this area: @mangod9 |
src/coreclr/vm/ceemain.cpp
Outdated
// Parameters: | ||
// thread - thread to detach | ||
// Return: | ||
// true if the thread was detached, false if there was no attached thread |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: just noticed the leftover comment when there was a return value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm. we will take for consideration in 9.0.x
Check with customer to test private. |
We see some issues with this in 10.0 See: #110801 |
Backport of #110589 to release/9.0-staging
/cc @VSadov
External threads that became known to the runtime (by running managed code via reverse PInvoke, for example) could cause a process-wide deadlock if the threads terminate during GC which happen to call an OS API that acquires the Loader Lock (launching background threads is just one example of such API).
Regression
The root cause was running thread termination routines directly or indirectly from DllMain. Thus the potential for the deadlock was present for a long time. However, the conditions for the deadlock are fairly narrow and the issue has not been known prior to the bug report.
It is likely that some changes in the timings around thread termination/creation made the deadlock more likely to happen in 9.0.
Testing
Regular testing.
This is a rare race condition with one of the requirements that a particular OS API is used.
Ensuring that the problematic API is no longer in use is more reliable validation than running tests,
Risk
Low.
The fix is essentially a switch to a different OS API/callback that does not run with Loader Lock acquired.
We have been using the same OS callback on NativeAOT for several releases.