Bug 73121 - top -i fails to display processes & their cpu times correctly
top -i fails to display processes & their cpu times correctly
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: procps (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-30 18:32 EDT by Joe Korty
Modified: 2007-04-18 12:46 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-11 08:04:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joe Korty 2002-08-30 18:32:22 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020724

Description of problem:
When the attached 11-line C program is run, top will not display
the execution times of the child, which in reality is at 99+%.

main()
{
    int pid, stat;
    if (pid = fork()) {
        /* parent */
        sleep(10000);
    } else {
        /* child */
        for (;;);
    }
}

This program displays fine under Redhat 7.2.  Some raw results:

Red Hat Linux release 7.3.94 ((null))
Kernel 2.4.18-11smp on an i686

[root@wahoo root]# top -i -d1

  5:33pm  up 2 min,  1 user,  load average: 0.59, 0.26, 0.10
40 processes: 38 sleeping, 2 running, 0 zombie, 0 stopped
CPU0 states:  1.0% user,  0.0% system,  0.0% nice, 99.0% idle
CPU1 states:  0.0% user,  0.0% system,  0.0% nice, 100.0% idle
CPU2 states: 101.0% user,  0.0% system,  0.0% nice,  0.0% idle
CPU3 states:  0.0% user,  0.0% system,  0.0% nice, 100.0% idle
Mem:  1030512K av,   56408K used,  974104K free,       0K shrd,    8340K buff
Swap: 2096472K av,       0K used, 2096472K free                   21196K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
  822 root      15   0   964  964   784 R     0.0  0.0   0:00 top

[root@wahoo root]# ps --forest

  PID TTY          TIME CMD
  740 ttyS0    00:00:00 bash
  805 ttyS0    00:00:00 tt
  806 ttyS0    00:01:04  \_ tt
  824 ttyS0    00:00:00 ps


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. compile attached c program: cc -O -o tt tt.c
2.  ./tt &
3.  watch -n1 ps --forest
4.  view for awhile, then kill.
5.  top -d1 -i
	

Additional info:

quad Dell server box.
Comment 1 Joe Korty 2002-08-30 18:34:26 EDT
This may be related to bug 70126, bug 71237, and bug 71244.
Comment 2 Joe Korty 2002-08-30 18:40:40 EDT
I booted a stock 2.4.18 kernel from ftp.kernel.org on Limbo(NULL); the
problem persists.  The same stock 2.4.18 kernel booted on a RedHat 7.2
system performed flawlessly.  Hence it appears the bug has nothing to
do with the kernel itself but with top, with the libraries it calls, or
with the new gcc 3.2 compiler.
Comment 3 Joe Korty 2002-08-30 19:14:58 EDT
When I grab procps-2.0.7.tar.gz from ftp.gnu.org and compile that
under Limbo(NULL), top works fine.  Therefore there is something
wrong with the way this package was compiled and packaged up into
an rpm.

I built a virgin package, no configuration changes of any kind.
Comment 4 Joe Korty 2002-08-30 19:21:34 EDT
The mysterious result of recompiling and everything works
might be explained if RedHat did not recompile  *every*
*single* rpm for Limbo(NULL), but instead passed through
some rpms built under Limbo2 ..

Note You need to log in before you can comment on or make changes to this bug.