-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Fix inverted gc contract condition for functions that may create a thread #119931
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
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.
Pull Request Overview
This PR fixes inverted garbage collector (GC) contract conditions in functions that may create threads in the CoreCLR runtime. The conditions were incorrectly specifying GC triggers for when a thread exists and disabled GC for when no thread exists, when it should be the opposite.
- Corrects the logic in CONTRACTL blocks across multiple CoreCLR VM files
- Ensures proper GC contract specifications for thread creation and management functions
- Affects functions in thread management, application domain operations, and host interface components
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
File | Description |
---|---|
src/coreclr/vm/threadsuspend.cpp | Fixed GC contracts in UserAbort and ResumeAllThreads functions |
src/coreclr/vm/threads.cpp | Corrected GC contracts in multiple thread lifecycle functions including constructors, setup, and cleanup |
src/coreclr/vm/corhost.cpp | Updated GC contracts in host interface methods for app domain and delegate operations |
src/coreclr/vm/appdomain.cpp | Fixed GC contracts in AppDomain friendly name operations |
Tagging subscribers to this area: @mangod9 |
I'll follow up on your comments and examine each method carefully, thanks |
Should CorHost2::ExecuteInAppDomain be GC_TRIGGERS since it invokes arbitrary code that might trigger GC? Isn't NOTHROW wrong for it too? |
Yes, that sounds right.
It catches all exceptions and converts them to HRESULT so it is NOTHROW. (NOTHROW means that no exception escapes. It does not prevent the implementation from throwing and caching.) |
Did a pass over everything and tried to update most of them so they aren't conditional. LMK if I got anything wrong. |
Following up on the non-contractL comments (I missed them originally) |
Think I got everything now. Sorry for the churn. |
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.
Thanks!
Thanks to @jkotas for noticing this