-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 3.6.0, 3.7.1
-
Component/s: Aggregation Framework, Querying
-
None
-
Fully Compatible
-
ALL
-
v3.6
-
Query 2018-05-07, Query 2018-05-21
-
19
Attempting to acquire a LockManager lock while holding a mutex is prone to deadlock. The CursorManager::killCursor() function locks the partition of CursorManager::_cursorMap corresponding to the specified cursor id. While holding the mutex, it calls ClientCursor::dispose(), which for an aggregation cursor attempts to acquire the collection lock in DocumentSourceCursor::cleanupExecutor() as part of DocumentSourceCursor::doDispose(). The "listCollections" and "listIndexes" commands hold the collection lock when attempting to call CursorManager::registerCursor(), forming the other edge of the deadlock cycle.
- is related to
-
SERVER-22541 Aggregation plan executors should be owned by global cursor manager
- Closed
-
SERVER-69143 CursorManager no longer needs to handle ClientCursor::dispose() outside of mutexes
- Open