[SERVER-33959] CursorManager attempts to dispose of aggregation cursors while holding partitioned lock, which leads to deadlock - MongoDB Jira

XML

Word

Printable

JSON

Details

Type: Bug
Status: Closed
Priority: Major - P3
Resolution: Fixed
Affects Version/s: 3.6.0, 3.7.1
Fix Version/s: 3.6.6, 4.0.0-rc0
Component/s: Aggregation Framework, Querying
Labels:
None

Backwards Compatibility:
Fully Compatible
Operating System:
ALL
Backport Requested:

v3.6
Sprint:
Query 2018-05-07, Query 2018-05-21
Linked BF Score:
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

Activity

People

Assignee:: Charlie Swanson

Reporter:: Max Hirschhorn

Participants:: Charlie Swanson, Githook User, Max Hirschhorn

Votes:: 0 Vote for this issue

Watchers:: 7 Start watching this issue

Dates

Created:: Mar 17 2018 07:24:53 PM UTC

Updated:: Aug 26 2022 04:13:07 PM UTC

Resolved:: May 15 2018 01:36:31 PM UTC