-
Notifications
You must be signed in to change notification settings - Fork 27
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
Avoid race conditions when the input attribute slice is shared #422
Conversation
|
h/t @MadVikingGod for the test case. briefly, this SDK was susceptible to all the same race conditions outlined in open-telemetry/opentelemetry-go#3943. As discussed in that thread, this SDK is organized to perform a map lookup before creating an attribute.Set; this persists, which is to say that the race condition has been corrected after the map lookup meaning there the fast path still has zero allocations. |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #422 +/- ##
==========================================
+ Coverage 87.85% 87.86% +0.01%
==========================================
Files 75 75
Lines 4282 4286 +4
==========================================
+ Hits 3762 3766 +4
Misses 445 445
Partials 75 75
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
Description:
Makes a copy of the attribute slice before calling NewSet to avoid race conditions when attribute.NewSet sorts the slice in place. Note that this is done after searching the map for a suitable exact match, prior to allocations, so benchmarks which measure re-use of existing attribute sets are not affected.
(Note that the call to NewSetWithSortable is no longer needed, since newer Go compilers are able to avoid that temporary.)
Link to tracking Issue: open-telemetry/opentelemetry-go#3943
Testing: A new test was added to exercise the input race condition.
Documentation: None added.