[SERVER-57347] Fix the data race in OpMsgFuzzerFixture Created: 01/Jun/21 Updated: 29/Oct/23 Resolved: 02/Jun/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.0-rc5, 5.1.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Amirsaman Memaripour | Assignee: | Amirsaman Memaripour |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | servicearch-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Backport Requested: |
v5.0
|
||||||||
| Sprint: | Service Arch 2021-06-14 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 69 | ||||||||
| Description |
|
The OpMsgFuzzerFixture resets the AuthorizationManager, which is a decoration on ServiceContext, after starting storage controls (i.e., startStorageControls). Starting the storage control enqueues a periodic task (i.e., JournalFlusher) that may attempt to access the AuthorizationManager, causing a data-race. We should reset the AuthorizationManager immediately after creating the new instance of ServiceContext (here) to avoid the data-race. |
| Comments |
| Comment by Vivian Ge (Inactive) [ 06/Oct/21 ] |
|
Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you! |
| Comment by Githook User [ 28/Jun/21 ] |
|
Author: {'name': 'Amirsaman Memaripour', 'email': 'amirsaman.memaripour@mongodb.com', 'username': 'samanca'}Message: (cherry picked from commit 3720d7e5cd419db95fdbf1b2df0dbd2f6d88ce56) |
| Comment by Githook User [ 02/Jun/21 ] |
|
Author: {'name': 'Amirsaman Memaripour', 'email': 'amirsaman.memaripour@mongodb.com', 'username': 'samanca'}Message: |