- Notifications
You must be signed in to change notification settings - Fork5.2k
[release/9.0-staging] [Profiler] Avoid Recursive ThreadStoreLock in Profiling Thread Enumerator#110665
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Merged
mdh1418 merged 4 commits intorelease/9.0-stagingfrombackport/pr-110548-to-release/9.0-stagingDec 19, 2024
Merged
[release/9.0-staging] [Profiler] Avoid Recursive ThreadStoreLock in Profiling Thread Enumerator#110665
mdh1418 merged 4 commits intorelease/9.0-stagingfrombackport/pr-110548-to-release/9.0-stagingDec 19, 2024
Uh oh!
There was an error while loading.Please reload this page.
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
Profiling Enumerators look to acquire the ThreadStoreLock.In release config, re-acquiring the ThreadStoreLock andreleasing it in ProfilerThreadEnum::Init will causeproblems if the callback invoking EnumThread has logicthat depends on the ThreadStoreLock being held.To avoid recursively acquiring the ThreadStoreLock,expand the condition when the profiling thread enumeratorshouldn't acquire the ThreadStoreLock.
There was a potential race condition when setting the flagbefore suspending and resetting the flag after restarting.For example, if the thread restarting runtime is preemptedright after resuming runtime, the flag could remain unsetby the time another thread looks to suspend runtime, whichwould see that the flag as set.
Contributor
Tagging subscribers to this area:@tommcdon |
tommcdon approved these changesDec 17, 2024
Member
mdh1418 commentedDec 19, 2024
Approved via email. |
7eb5ef2 intorelease/9.0-staging 97 of 101 checks passed
Uh oh!
There was an error while loading.Please reload this page.
Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.
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.
Uh oh!
There was an error while loading.Please reload this page.
Backport of#110548 to release/9.0-staging
/cc@mdh1418
Customer Impact
#110062
Profiler users invoking
EnumThreadswithin aRuntimeSuspendFinishedcallback will cause aninfinite wait because theEnumThreadswill recursively acquire/release the ThreadStore lock.Regression
This did not occur in .NET 8.0. The recursive ThreadStoreLock acquire/release was always there, butthe condition that previously prevented this case causing an infinite wait was removed in#101782
Testing
The issue was reproduced locally and the fix was confirmed locally.
The issue was missed previously because there were no profiler tests covering this edge-case scenario. It is hard to cover all the ways our customers will use Profiler APIs.
A runtime test was added for this particular scenario, invoking the
EnumThreadsAPI within aRuntimeSuspendFinishedcallback.Risk
Low. The changes only affect Profiler users that specifically invoke
EnumThreadswithin aRuntimeSuspendFinishedcallback and trigger a GC.IMPORTANT: If this backport is for a servicing release, please verify that:
release/X.0-staging, notrelease/X.0.Package authoring no longer needed in .NET 9
IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.