Fix ReusableStringStream to access the container under the lock#3031
Fix ReusableStringStream to access the container under the lock#3031horenmar merged 1 commit intocatchorg:develfrom dunhor:devel
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## devel #3031 +/- ##
=======================================
Coverage 90.77% 90.77%
=======================================
Files 201 201
Lines 8707 8707
=======================================
Hits 7903 7903
Misses 804 804 🚀 New features to boost your workflow:
|
|
Hmm. I applied the patch to our build, but now ASan happened to hit a double free. I'll need to investigate this some more. https://dev.azure.com/msft-wil/3aea0394-d119-4b82-84fa-a5186532efe9/_apis/build/builds/1419/logs/56 |
Woops, I'm dumb. The thread support needs to be explicitly enabled. Still, this is a legitimate bug since concurrent access to the vector is unsafe as another thread can be calling |
|
Thanks, I completely missed the potential for resize when figuring out where to take the lock. |
Description
Commit 582200a made
ReusableStringStream's index reservation thread safe, however it's still accessing them_streamsvector outside the lock. This makes it so that theaddcall returns the pointer in addition to the index so that the lock doesn't need to get acquired again until destruction.The issue with accessing
m_streamsoutside the lock is thataddcan callpush_backon the vector, which might re-allocate. If this re-allocation occurs concurrently with anther thread trying to index into this array, you get UB (typically a null pointer read).