[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:
Duplicate
Related
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.

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