[SERVER-28860] Coverity analysis defect 100781: Thread deadlock Created: 19/Apr/17  Updated: 27/Oct/23  Resolved: 19/Jul/17

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Coverity Collector User Assignee: William Schultz (Inactive)
Resolution: Works as Designed Votes: 0
Labels: coverity
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-28862 Coverity analysis defect 100778: Thre... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2017-07-31
Participants:

 Description   

Threads may try to acquire two locks in different orders, potentially causing deadlock

Defect 100781 (STATIC_C)
Checker ORDER_REVERSAL (subcategory none)
File: /src/mongo/db/repl/database_cloner.cpp
Function mongo::repl::DatabaseCloner::_collectionClonerCallback(const mongo::Status &, const mongo::NamespaceString &)



 Comments   
Comment by William Schultz (Inactive) [ 06/Jul/17 ]

The Coverity analysis claims that we recursively acquire the DatabaseCloner::_mutex in DatabaseCloner::_collectionClonerCallback when we call DatabaseCloner::_finishCallback_inlock which calls DatabaseCloner::_finishCallback_inlock. However, DatabaseCloner::_finishCallback_inlock always unlocks the lock first if necessary, avoiding this scenario.

Generated at Thu Feb 08 04:19:15 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.