[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) |
| 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. |