fix(profiling): fix data race when accessing span for thread [backport 2.13] #11214
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport 64b3374 from #11167 to 2.13.
The ThreadSpanLinks singleton holds the active span (if one exists) for
a given thread ID. The
get_active_span_from_thread_idmember functionreturns a pointer to the active span for a thread. The
link_spanmember function sets the active span for a thread.
get_active_span_from_thread_idaccesses the map of spans under amutex, but returns the pointer after releasing the mutex, meaning
link_spancan modify the members of the Span while the caller ofget_active_span_from_thread_idis reading them.Fix this by returning a copy of the
Span. Use astd::optionalto wrapthe return value of
get_active_span_from_thread_id, rather thanreturning a pointer. We want to tell whether or not there actually was a
span associated with the thread, but returning a pointer would require
us to heap allocate the copy of the Span.
I added a simplistic regression test which fails reliably without this
fix when built with the thread sanitizer enabled. Output like:
(cherry picked from commit 64b3374)
Checklist
Reviewer Checklist