[SERVER-40619] Coverity analysis defect 112447: Thread deadlock Created: 12/Apr/19  Updated: 12/Apr/19  Resolved: 12/Apr/19

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

Type: Bug Priority: Major - P3
Reporter: Coverity Collector User Assignee: Mira Carey
Resolution: Won't Fix Votes: 0
Labels: coverity
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Sprint: Service Arch 2019-04-22
Participants:

 Description   

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

Defect 112447 (STATIC_C)
Checker ORDER_REVERSAL (subcategory none)
File: /src/mongo/util/background_thread_clock_source.cpp
Function mongo::BackgroundThreadClockSource::_updateClockAndWakeTimerIfNeeded()



 Comments   
Comment by Eric Milkie [ 12/Apr/19 ]

What kind of a static analyzer would it be if it couldn't do that? =)

Comment by Mira Carey [ 12/Apr/19 ]

This would only be a problem if we used the BackgroundThreadClockSource with the AutoAdvancingClockSourceMock. In production we use the BackgroundThreadClockSource with a real system clock source. In the BTCS test, we use it with a regular clock source mock. I don't think it's a problem that you can't use these two types together (and I'm impressed/horrified that coverity can apparently match up call sites with all possible base classes it can find definitions for)

Comment by Eric Milkie [ 12/Apr/19 ]

I think this is saying that if you were to try to use the BackgroundThreadClockSource with the ClockSourceMock (e.g. in a unit test), you would self-deadlock.

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