[SERVER-32485] mongodb-dump-locks GDB command may block if mongod process already in midst of logging to console Created: 29/Dec/17 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Max Hirschhorn | Assignee: | Backlog - Server Tooling and Methods (STM) (Inactive) |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | move-sdp-candidate, tig-hanganalyzer | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Server Tooling & Methods
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
The mongodb-dump-locks command calls LockManager::dump() on the globalLockManager instance, which attempts to write the LockManager's lock state information to the mongod's stdout pipe via calls to log(). If another thread is already in the midst of logging to the console, then calling the LockManager::dump() function will block upon constructing another Console instance. We should either (a) depend only on mongodb-show-locks and stop calling the mongodb-dump-locks command in hang_analyzer.py, or (b) add a version of LockManager::dump() that returns a string and doesn't attempt to call the log() function so that GDB can print the lock state messages itself. |
| Comments |
| Comment by Steven Vannelli [ 10/May/22 ] |
|
Moving this ticket to the Backlog and removing the "Backlog" fixVersion as per our latest policy for using fixVersions. |
| Comment by Andy Schwerin [ 31/Dec/17 ] |
|
I vote for a version of Lock manager::dump that takes a `std::ostream&` and writes to it. |