Bug 37702

Summary:	/usr/bin/top uses 100% cpu in 'system'
Product:	Base System	Reporter:	Avleen Vig <lists-sendpr>
Component:	bin	Assignee:	dwmalone
Status:	Closed FIXED
Severity:	Affects Only Me	CC:	lists-sendpr
Priority:	Normal
Version:	4.4-RELEASE
Hardware:	Any
OS:	Any

Description Avleen Vig 2002-05-03 10:40:01 UTC

Running 'top -s' gives the following error:
top: option requires an argument -- s
Top version 3.4

But running 'top -s -o size' starts top and causes it to update
as fast as it can. This increases load (rate if increase depends
on box specs and other running procs), while top takes up as much
CPU time as it can.

After 5 mins on a very load load box:
load averages:  1.53,  0.85,  0.45

On a box where the initial load is:
load averages:  3.16,  1.95,  1.00
After 5 minute of broken top, we get:
load averages:  5.24,  3.91,  1.98

http_load also shows that requests don't always seem to complete
(ok, it's not the best test)
--- 60.0106 secs, 249 fetches started, 199 completed, 50 current

Fix: 

Unknown
How-To-Repeat: Run: 'top -s -o size'. I don't recommend doing this on a heavily
loaded box straight away. Try it on your desktop. You can still
quit top easily with the 'q' key.

Comment 1 edwin 2002-05-03 13:47:44 UTC

On Fri, May 03, 2002 at 09:33:13AM -0000, Avleen Vig wrote:
> >How-To-Repeat:
> Run: 'top -s -o size'. I don't recommend doing this on a heavily
> loaded box straight away. Try it on your desktop. You can still
> quit top easily with the 'q' key.
> 
> >Fix:
> Unknown

Problem is that the handling of arguments is a little bit broken.
For 4.5, the patch would be:

--- /usr/src/contrib/top/top.c.old   Fri May  3 22:38:48 2002
+++ /usr/src/contrib/top/top.c       Fri May  3 22:39:14 2002
@@ -317,10 +317,10 @@
                break;
 
              case 's':
-               if ((delay = atoi(optarg)) < 0)
+               if ((delay = atoi(optarg)) <= 0)
                {
                    fprintf(stderr,
-                       "%s: warning: seconds delay should be non-negative -- using default\n",
+                       "%s: warning: seconds delay should be postive -- using default\n",
                        myname);
                    delay = Default_DELAY;
                    warnings++;

With this information a similair patch for -current would be easy to make.

The handling of the fact that the integer value of "size" is
translated into 0 and is displaying zero lines of process-output
is not tackled by this, since people might want to display zero
processes and have only the summary.

Edwin

-- 
Edwin Groothuis      |           Personal website: http://www.MavEtJu.org
edwin@mavetju.org    |        Interested in MUDs? Visit Fatal Dimensions:
bash$ :(){ :|:&};:   |                    http://www.FatalDimensions.org/

Comment 2 Bruce Evans 2002-05-05 01:39:24 UTC

On Sat, 4 May 2002, David Malone wrote:

> On Fri, May 03, 2002 at 05:50:07AM -0700, Edwin Groothuis wrote:
> >                case 's':
> >  -               if ((delay = atoi(optarg)) < 0)
> >  +               if ((delay = atoi(optarg)) <= 0)
> >                  {
>
> I think this has been fixed in -current in another way:
>
> 	if ((delay = atoi(optarg)) < 0 || (delay == 0 && getuid() != 0))
>
> this means you're only alowd to get continious updates if you're
> root. (This change came from the last beta version of top which
> was released by the original authors.)

-current still has the bad options parsing, and a delay of 0 causes
strange synchronization at least on syscons consoles: the
user/nice/system/interrupt/idle percentages are usually all displayed
as "0.0".

Bruce

Comment 3 dwmalone freebsd_committer

2002-05-06 09:48:17 UTC

Responsible Changed
From-To: freebsd-bugs->dwmalone

Top PR for me.

Comment 4 dwmalone freebsd_committer

2002-08-11 19:04:26 UTC

State Changed
From-To: open->closed

This problem is fixed for regular users with the version of top I 
just MFCed. It still allows root to run "top -s 0", which produces 
weird output, but that might be useful for some.