utah on phablet polls on select() and consumes 100% CPU
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
UTAH |
Fix Released
|
High
|
Andy Doan |
Bug Description
I ran a test that did a considerable amount of package installation via a bash script that was invoked by tc_setup and noticed that UTAH was burning up one CPU at 100%.
I attached strace to the utah process and noticed a very tight select loop:
select(13, [8 12], [], [], {0, 0}) = 0 (Timeout)
select(13, [8 12], [], [], {0, 0}) = 0 (Timeout)
select(13, [8 12], [], [], {0, 0}) = 0 (Timeout)
select(13, [8 12], [], [], {0, 0}) = 0 (Timeout)
select(13, [8 12], [], [], {0, 0}) = 0 (Timeout)
..
ad nauseum
So, polling on a zero timeout with a zero timeout is a bit wrong isn't it?
Although this does not seem to affect the test once it runs, I'm a bit concerned that that may be more occurrences of this kind kind of select() polling in utah which we've not caught. This is the 2nd CPU burner polling loop I've hit sofar, so that makes me wonder if there are any more.
Related branches
- UTAH Dev: Pending requested
-
Diff: 12 lines (+1/-1)1 file modifiedutah/process.py (+1/-1)
Changed in utah: | |
status: | New → Fix Committed |
status: | Fix Committed → New |
Changed in utah: | |
status: | New → In Progress |
Changed in utah: | |
status: | In Progress → Fix Released |
milestone: | none → 0.13 |
its a single function, the thing I have to determine is why we'd call select with a 0 timeout. I thought this shouldn't happen.
relevant files to help produce:
http:// paste.ubuntu. com/5780965/ paste.ubuntu. com/5780965/ paste.ubuntu. com/5780968/
http://
http://