gops: Gops hangs if there are too many Go processes to examine
If you have more than ten (I believe) Go processes, gops will hang in goprocess/gp.go’s FindAll() function. This happens because the ‘for … range pss { …}’ loop attempts to obtain a limitCh token before starting the goroutine, but the goroutines only release their token after they have sent their reply to the found
channel. Since the found
channel is unbuffered and is only read from by the main code after the ‘for … range pss {}’ loop finishes, this deadlocks if the number of goroutines would ever be limited.
I think either the entire ‘for … range pss { … }’ loop needs to be in a goroutine so that it doesn’t block reading from the found
channel, or the limitCh
token must be released by the code before sending to found
. The former change seems easier and I think it’s correct.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 5
- Comments: 17 (8 by maintainers)
Commits related to this issue
- Fix the worker concurrency model Limit the number of concurrent workers by starting a fixed number of goroutines and providing work by an input channel. Fixes #123 — committed to rakyll/gops by rakyll 4 years ago
- Fix the worker concurrency model (#126) Limit the number of concurrent workers by starting a fixed number of goroutines and providing work by an input channel. Fixes #123 — committed to google/gops by rakyll 4 years ago
- Added tests for `goprocess`. The tests verify #123 fix and prevent future regressions. — committed to yarcat/gops by yarcat 4 years ago
- goprocess: add test for FindAll (#127) The test verifies that #123 is fixed and prevents future regressions. — committed to google/gops by yarcat 4 years ago
I see now. Using len(pss) would work.
It seems to me the simplest fix would be to make
found
buffered, with sizeconcurrencyProcesses
.