Bug 77036 - resizing top causes Floating point exception
resizing top causes Floating point exception
Product: Red Hat Linux
Classification: Retired
Component: procps (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-10-31 00:00 EST by Joseph Shraibman
Modified: 2007-04-18 12:48 EDT (History)
1 user (show)

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

Attachments (Terms of Use)

  None (edit)
Description Joseph Shraibman 2002-10-31 00:00:31 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

Description of problem:
When running top in an xterm, resizing the window causes top to crash.

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

How reproducible:

Steps to Reproduce:
1. Run top in an xterm
2. Resize the xterm

Actual Results:   11:51pm  up  3:25,  1 user,  load average: 0.00, 0.00, 0.00
41 processes: 40 sleeping, 1 running, 0 zombie, 0 stopped
Floating point exception

Additional info:

This is a dual Xenon machine with hyperthreading (so linux sees 4 cpus). It
normally looks like this:

 11:58pm  up  3:31,  1 user,  load average: 0.00, 0.00, 0.00
41 processes: 40 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states:  0.0% user,  0.0% system,  0.0% nice, 100.0% idle
CPU1 states:  0.0% user,  0.0% system,  0.0% nice, 100.0% idle
CPU2 states:  0.0% user,  0.0% system,  0.0% nice, 100.0% idle
CPU3 states:  0.0% user,  2.0% system,  0.0% nice, 97.4% idle
Mem:  1030500K av,  150908K used,  879592K free,       0K shrd,   38060K buff
Swap: 2040244K av,       0K used, 2040244K free                   78068K cached

Workaround: resize the xterm before running top
Comment 1 Leonid Mamtchenkov 2002-10-31 04:47:48 EST
I have seen similar problem.  The difference was in that I didn't have to resize
xterm, or  to run top in the GUI at all.  It segfaulted in text mode aswell. 
From what I was able to dig, this was a problem with shared memory (strange
though).  Check the output of ipcs command, and try to remove unused segments
with ipcrm.  That helped my case.
Comment 2 Joseph Shraibman 2002-10-31 14:09:43 EST
I just reproduced the bug with ipcs reporting no shared memory (basically this
machine hasn't run anything since it was booted)
Comment 3 Leonid Mamtchenkov 2002-11-01 03:54:24 EST
I've just found out that one of my Redhat 7.2 machines has the problem.  Funny
thing is that if I just run "top", I get this:

 10:53am  up 290 days, 16:57,  2 users,  load average: 0.04, 0.11, 0.09
147 processes: 146 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states:  0.0% user, 100.0% system,  0.0% nice,  0.0% idle
Floating point exception

But if I run "strace top", then it works just fine. ;)  Go figure...
Comment 4 Joseph Shraibman 2002-11-04 17:39:01 EST
Maybe because strace floods the connection with data, and this is a timing issue?
Comment 5 Alexander Larsson 2002-11-05 07:04:30 EST
I thought this was a dup of bug 67200, but that one has been fixed in 8.0. I
can't personally reproduce this bug.

Does top -d0 reproduce the bug for you?

Can you see if this fixes it:
Comment 6 Leonid Mamtchenkov 2002-11-05 07:14:32 EST
I, myself, don't have any 8.0 machine that has this problem.  But on the 7.2
machine, problem appears both with and without "-d0".  The RPM you mentioned,
failed to upgrade (probably, for RedHat 7.3 or 8.0):
[root@webber1 tmp]# rpm -Uvh procps-2.0.10-2.i386.rpm 
error: failed dependencies:
        libc.so.6(GLIBC_2.3)   is needed by procps-2.0.10-2

Current version of procps for that machine is:
[root@webber1 tmp]# rpm -qa | grep procps
Comment 7 Alexander Larsson 2002-11-05 07:28:43 EST
Ah, yes. That rpm is for 8.0, try downloading the SRPM instead:
build it with rpmbuild --rebuild procps-2.0.10-2.src.rpm and install.

But the problem with 7.2 is almost certainly a dup of bug 67200, and known to be
fixed. I'm more interested in failures on 8.0.
Comment 8 Leonid Mamtchenkov 2002-11-05 07:48:56 EST
New RPM fixed the problem both with and without "-d0" on 7.2.  Thanks.
Comment 9 Joseph Shraibman 2002-11-05 13:46:34 EST
I just tried to reproduce the bug so I could do a before/after comparison, but I
can't reproduce it right now :(  I'll keep trying.
Comment 10 Daniel Walsh 2004-02-11 08:18:33 EST
I am closing this bug as it seems to be fixed and is over a year old.
 Major new version of procps is also out.  Reopen it if you can get it
with the current version.

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