Bug 13557
| Summary: | [PATCH] top(1) sorts processes incorrectly | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Eric Peters <epeters> | ||||
| Component: | bin | Assignee: | Mike Heffner <mikeh> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | 3.2-STABLE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
State Changed From-To: open->feedback Can you report if this was fixed by rev 1.28 of machine.c? Responsible Changed From-To: freebsd-bugs->mikeh I'll handle feedback. State Changed From-To: feedback->closed Feedback timeout. |
When running top(1) sorting by 'time' (top -otime) top(1) fails to sort correctly some processes that have accumulated excessive runtime. Turns out top(1) compares the time processes have run (proc.p_runtime) and stores the result in an interger. Not bad in itself, but p_runtime is a 64bit value. Fix: Apply the following patch. Although I can verify its sanity, the code involved has a smell of 'optimized' & I won't pretend knowing how this mangles it or how best to nudge things into good order. How-To-Repeat: start a long-running process, such as #!/usr/bin/perl do{}while 1 (I am sure more productive examples abound.) Check 'top -otime' periodiocaly (about 8.5 hours in should work, but I suspect this may present itself earlier).