Skip to content
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

Fix EventSource deadlock #71574

Merged
merged 2 commits into from
Jul 7, 2022
Merged

Conversation

noahfalk
Copy link
Member

@noahfalk noahfalk commented Jul 2, 2022

Initializing NativeRuntimeEventSource inside the EventListener static constructor
could lead to a deadlock where a 2nd thread holding the ETW lock calls back
though ETWCallback and tries to get EventListener lock which blocks on the
static constructor.

Fixes #70870

Initializing NativeRuntimeEventSource inside the EventListener static constructor
could lead to a deadlock where a 2nd thread holding the ETW lock calls back
though ETWCallback and tries to get EventListener lock which blocks on the
static constructor.

Fixes dotnet#70870
Interlocked.CompareExchange(ref s_EventSources, new List<WeakReference<EventSource>>(2), null);
#if FEATURE_PERFTRACING
// It is possible that another thread could observe the s_EventSources list at this point and it
// won�t have the NativeRuntimeEventSource in it. In the past we guaranteed that the NativeRuntimeEventSource
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like some non-ASCII characters are trying to sneak in

// It is possible that another thread could observe the s_EventSources list at this point and it
// won�t have the NativeRuntimeEventSource in it. In the past we guaranteed that the NativeRuntimeEventSource
// was always visible in the list by initializing it in the EventListener static constructor, however doing it
// that way triggered deadlocks between the static constructor and an OS ETW lock. As best I can tell
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: can we avoid using "I" in such comments? After this PR who "I" is throughout the code becomes inconsistent and ambiguous.

@noahfalk
Copy link
Member Author

noahfalk commented Jul 7, 2022

CI failure is known issue: #71684

@noahfalk noahfalk merged commit ac83230 into dotnet:main Jul 7, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Aug 7, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Deadlock in EventListener static constructor
2 participants