-
Type: Bug
-
Resolution: Works as Designed
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Query Execution
-
ALL
-
Repl 2024-05-13
Check of thread-shared field evades lock acquisition
The data guarded by this critical section may be read while in an inconsistent state or modified by multiple racing threads. Checking the value of a thread-shared field outside of a locked region to determine if a locked operation involving that thread shared field has completed.
/src/mongo/db/repl/replication_coordinator_impl.cpp:1367: LOCK_EVASION 154627 Thread1 acquires lock "mongo::repl::ReplicationCoordinatorImpl._mutex".
/src/mongo/db/repl/replication_coordinator_impl.cpp:1368: LOCK_EVASION 154627 Thread1 uses the value read from field "_oplogSyncState" in the condition "this->_oplogSyncState != mongo::repl::ReplicationCoordinator::OplogSyncState::ApplierDraining". It sees that the condition is false. Control is switched to Thread2.
/src/mongo/db/repl/replication_coordinator_impl.cpp:1367: LOCK_EVASION 154627 Thread2 acquires lock "mongo::repl::ReplicationCoordinatorImpl._mutex".
/src/mongo/db/repl/replication_coordinator_impl.cpp:1368: LOCK_EVASION 154627 Thread2 uses the value read from field "_oplogSyncState" in the condition "this->_oplogSyncState != mongo::repl::ReplicationCoordinator::OplogSyncState::ApplierDraining". It sees that the condition is false.
/src/mongo/db/repl/replication_coordinator_impl.cpp:1397: LOCK_EVASION 154627 Thread2 sets "_oplogSyncState" to a new value. Note that this write can be reordered at runtime to occur before instructions that do not access this field, even into (but not to the other side of) preceding locked regions. Control is switched back to Thread1.
/src/mongo/db/repl/replication_coordinator_impl.cpp:1387: LOCK_EVASION 154627 Thread1 acquires lock "std::unique_lock<std::mutex>._M_device".
/src/mongo/db/repl/replication_coordinator_impl.cpp:1397: LOCK_EVASION 154627 Thread1 sets "_oplogSyncState" to a new value. Now the two threads have an inconsistent view of "_oplogSyncState" and updates to fields correlated with "_oplogSyncState" may be lost.
/src/mongo/db/repl/replication_coordinator_impl.cpp:1398: LOCK_EVASION 154627 Any code run after the execution of "this->_oplogSyncState = mongo::repl::ReplicationCoordinator::OplogSyncState::Stopped;" may not necessarily run when a second thread reaches "if (this->_oplogSyncState != mongo::repl::ReplicationCoordinator::OplogSyncState::ApplierDraining || !this->_topCoord->canCompleteTransitionToPrimary(termWhenExhausted))".
/src/mongo/db/repl/replication_coordinator_impl.cpp:1385: LOCK_EVASION 154627 The modification of "millis" can race with the unguarded check of "_oplogSyncState".
/src/mongo/db/repl/replication_coordinator_impl.cpp:1417: LOCK_EVASION 154627 The modification of "currConfigVersionAndTerm" can race with the unguarded check of "_oplogSyncState".