Possible race conditions

[daladim]

Race 1

There is no specific synchronization mechanism in trace_callback_thunk(). Which means a thread could be closing the trace session and destroying the TraceData, just at the same time the last callback was triggered. And the event_record.user_context dereferenced in another thread, supposed to point to a TraceData could be dangling here

Race 2

If a thread closes the trace session and destroys the TraceData, the associated Provider, hence the associated callbacks, which are closures, are dropped. That's a problem in case a callback is still in progress (e.g. a callback is stuck in a blocking function call), because the closure may contain state (e.g. in a move || closure).

Notes

krabsetw may have the same issues. See the issue in krabsetw

[daladim]

I'm on my way to fix it.

But this (more or less) requires some changes to make the unsafes less unsafe. E.g.

• [x] have a Builder pattern, and less pub members, to guarantee more data stays constant during the lifetime of the trace session. Because having non-mutable data is a requirement when accessing this data from a raw pointer (e.g. the one given by the ETW callback)
• [x] To make the review easier, I may simplify some types (e.g. remove the distinction between TraceInfo and EventTraceProperties, or flatten some data from TraceInfo into TraceData, remove the fill_info() functions, etc.
• [ ] etc.

[daladim]

Note that race 2 is rather likely. If CloseTrace returns an ERROR_CTX_CLOSE_PENDING, this means the callback will be invoked again, after we may be tempted to drop the closure.

[daladim]

Both races have been fixed, and fixes are included in ferrisetw 1.0