[SERVER-28861] Coverity analysis defect 100779: Thread deadlock Created: 19/Apr/17 Updated: 06/Dec/22 Resolved: 02/Jan/20 |
|
| 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: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | coverity, neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding
|
| Operating System: | ALL |
| Sprint: | Sharding 2017-10-02 |
| Participants: |
| Description |
|
Threads may try to acquire two locks in different orders, potentially causing deadlock Defect 100779 (STATIC_C) |
| Comments |
| Comment by Sheeri Cabral (Inactive) [ 02/Jan/20 ] |
|
This is a valid bug but the mock is used in single-threaded unit tests, and not seen in the wild or in testing. |
| Comment by Misha Tyulenev [ 21/Nov/17 ] |
|
Moving to Backlog as this is an issue that is not possible for production code because the BackgroundThreadClockSource::now() does not use mutexes its an atomic. The suggested fix should change the ClockSourceMock::_now to an atomic implementation so it will not need mutexes. |
| Comment by Spencer Brody (Inactive) [ 12/Jul/17 ] |
|
Assigning to sharding team since this involves the LogicalClock |
| Comment by William Schultz (Inactive) [ 06/Jul/17 ] |
|
The issue Coverity picked up on has to deal with inconsistent lock acquisition order, involving the LogicalClock::_mutex and the NetworkInterfaceMock::_mutex, leading to a potential deadlock. Consider the following two functions, and the order that they acquire locks: LogicalClock::reserveTicksNetworkInterfaceMock::_scheduleResponse
Since these two functions acquire the same two locks but in reverse orders, it creates the potential for a deadlock, if each of these functions are running on separate threads and try to acquire the locks with a specific thread interleaving. I presume that the NetworkInterfaceMock would only be used for testing, and so is not a serious issue. |