[SERVER-28905] Coverity analysis defect 101499: Waiting while holding a lock Created: 21/Apr/17  Updated: 27/Oct/23  Resolved: 15/May/17

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

Type: Bug Priority: Major - P3
Reporter: Coverity Collector User Assignee: Nathan Myers
Resolution: Works as Designed Votes: 0
Labels: coverity
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2017-05-29
Participants:

 Description   

A lock is held while waiting for a long running or blocking operation to complete

Defect 101499 (STATIC_C)
Checker SLEEP (subcategory none)
File: /src/mongo/db/s/collection_range_deleter.cpp
Function mongo::CollectionRangeDeleter::cleanUpNextRange(mongo::OperationContext , const mongo::NamespaceString &, int, mongo::CollectionRangeDeleter)

File: /src/mongo/db/s/collection_range_deleter.cpp
Function mongo::CollectionRangeDeleter::cleanUpNextRange(mongo::OperationContext , const mongo::NamespaceString &, int, mongo::CollectionRangeDeleter)



 Comments   
Comment by Eric Milkie [ 21/Apr/17 ]

You're right – it must not be modeling lock_guard correctly. It clearly falls out of scope after that anonymous block.

Comment by Kaloian Manassiev [ 21/Apr/17 ]

In this case Coverity mistakenly thinks that the lock taken on line 106 is still held by the time waitForWriteConcern is called.

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