Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Fixed
-
3.6.0, 3.7.1
-
None
-
Fully Compatible
-
ALL
-
v3.6
-
Query 2018-05-07, Query 2018-05-21
-
19
Description
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.
Attachments
Issue Links
- 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
-