Uh oh!
There was an error while loading. Please reload this page.
Make sure EventPipe streaming thread won't write session->streaming_thread after session free. - #58615
Conversation
…hread after session free. In case where ep_disable is called by a different thread (close IPC command) there was a race between streaming threads setting session->streaming_thread to NULL and IPC command triggering a call to disable_holding_lock and freeing session. Resetting the streaming_thread in streaming thread must happens before it signals its shutdown event to prevent the race.
lateralusX
commented
Sep 3, 2021
//CC @josalem |
josalem
left a comment
There was a problem hiding this comment.
I'm getting major déjà vu from this change, but I can't seem to find a previous patch that matches this change.
That aside, this LGTM. Thanks!
josalem
commented
Sep 3, 2021
We should try to backport this change to release/6.0 for rc2. |
Yes, I fixed another incarnation of this issue in an error case I hit locally where we wrote to memory after free on the same thread, #53886 but missed that the same scenario might be hit when the streaming thread is racing with IPC stop tracing command on different thread. |
lateralusX
commented
Sep 6, 2021
/backport to release/6.0 |
Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/1204902529 |
In case where
ep_disableis called by a different thread (stop tracing IPC command) there was a race between streaming thread settingsession->streaming_threadtoNULLand IPC command triggering a call todisable_holding_lockand freeing session.Resetting the
session->streaming_threadin streaming thread must happens before it signals its shutdown event to prevent the race causing heap corruption, writing NULL into freed memory.Probably root cause of #57461.