You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When an app calls EventSource.GetSources(), (or many other EventSource APIs that would trigger calling EventListener.cctor) it may deadlock. Thread A holds the implicit lock on the static constructor and blocks trying to acquire an internal ETW OS lock. Thread B runs a callback from the OS where the ETW lock is held and blocks trying to acquire the implicit .cctor lock.
Probably we should fix this by removing the call to initialize the RuntimeEventSource from the EventListener .cctor and finding some other place to do that.
Reproduction Steps
We don't have deterministic repro, but it was observed from a small .NET 6 windows app that calls EventSource.GetSources() + lucky timing. Putting a Sleep() inside EventListener.cctor would probably make it much easier to hit.
Expected behavior
EventSource.GetSources() doesn't block
Actual behavior
EventSource.GetSources() blocks
Regression?
Uncertain at this point
Known Workarounds
No response
Configuration
Windows .NET 6 x64 (architecture probably doesn't matter)
Other information
No response
The text was updated successfully, but these errors were encountered:
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.
Fixesdotnet#70870
* Fix EventSource deadlock
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
ghost
removed
the
in-pr
There is an active PR which will close this issue when it is merged
label
Jul 7, 2022
ghost
locked as resolved and limited conversation to collaborators
Aug 7, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
When an app calls EventSource.GetSources(), (or many other EventSource APIs that would trigger calling EventListener.cctor) it may deadlock. Thread A holds the implicit lock on the static constructor and blocks trying to acquire an internal ETW OS lock. Thread B runs a callback from the OS where the ETW lock is held and blocks trying to acquire the implicit .cctor lock.
Thread A
Thread B
Probably we should fix this by removing the call to initialize the RuntimeEventSource from the EventListener .cctor and finding some other place to do that.
Reproduction Steps
We don't have deterministic repro, but it was observed from a small .NET 6 windows app that calls EventSource.GetSources() + lucky timing. Putting a Sleep() inside EventListener.cctor would probably make it much easier to hit.
Expected behavior
EventSource.GetSources() doesn't block
Actual behavior
EventSource.GetSources() blocks
Regression?
Uncertain at this point
Known Workarounds
No response
Configuration
Windows .NET 6 x64 (architecture probably doesn't matter)
Other information
No response
The text was updated successfully, but these errors were encountered: