-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
EventPipe: Don't clean up thread list on shutdown #96936
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.
I think we should revisit the shutdown/uninitialize approach of EventPipe at some time, so we can split what's being called at shutdown vs potential unloading of the library in embedding scenarios in cases where the process continue to execute after the runtime has been unloaded and potentially reloaded.
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.
👍
Build analysis says all failures are known, merging. |
/backport to release/8.0-staging |
Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/7577481505 |
We had a report of a crash in EventPipe where the app was shutting down, and after
_ep_threads_lock
was freed a new thread was trying to fire an event and ran in to an AV trying to lock_ep_threads_lock
to check if the thread was known.This PR cleans up some dead code and makes
_ep_threads_lock
follow the approach we've been taking for some time now, to not clean up and let the OS deal with it after process exit.