[release/9.0-staging] [Profiler] Avoid Recursive ThreadStoreLock in Profiling Thread Enumerator#110665
Merged
mdh1418 merged 4 commits intorelease/9.0-stagingfrom Dec 19, 2024
Conversation
Profiling Enumerators look to acquire the ThreadStoreLock. In release config, re-acquiring the ThreadStoreLock and releasing it in ProfilerThreadEnum::Init will cause problems if the callback invoking EnumThread has logic that depends on the ThreadStoreLock being held. To avoid recursively acquiring the ThreadStoreLock, expand the condition when the profiling thread enumerator shouldn't acquire the ThreadStoreLock.
There was a potential race condition when setting the flag before suspending and resetting the flag after restarting. For example, if the thread restarting runtime is preempted right after resuming runtime, the flag could remain unset by the time another thread looks to suspend runtime, which would see that the flag as set.
ghost
added
the
Contributor
|
Tagging subscribers to this area: @tommcdon |
tommcdon
approved these changes
Dec 17, 2024
Member
|
Approved via email. |
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
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.
Backport of #110548 to release/9.0-staging
/cc @mdh1418
Customer Impact
#110062
Profiler users invoking
EnumThreadswithin aRuntimeSuspendFinishedcallback will cause an infinite 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, but the 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.