Bug 77036 - resizing top causes Floating point exception
Summary: resizing top causes Floating point exception
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: procps
Version: 8.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-10-31 05:00 UTC by Joseph Shraibman
Modified: 2007-04-18 16:48 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-02-11 13:18:33 UTC
Embargoed:


Attachments (Terms of Use)

Description Joseph Shraibman 2002-10-31 05:00:31 UTC
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:
Sometimes

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

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 09:47:48 UTC
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 19:09:43 UTC
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 08:54:24 UTC
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 22:39:01 UTC
Maybe because strace floods the connection with data, and this is a timing issue?

Comment 5 Alexander Larsson 2002-11-05 12:04:30 UTC
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:
ftp://ftp.redhat.com/pub/redhat/linux/rawhide/i386/RedHat/RPMS/procps-2.0.10-2.i386.rpm

Comment 6 Leonid Mamtchenkov 2002-11-05 12:14:32 UTC
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
procps-2.0.7-11


Comment 7 Alexander Larsson 2002-11-05 12:28:43 UTC
Ah, yes. That rpm is for 8.0, try downloading the SRPM instead:
ftp://ftp.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS/procps-2.0.10-2.src.rpm
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 12:48:56 UTC
New RPM fixed the problem both with and without "-d0" on 7.2.  Thanks.

Comment 9 Joseph Shraibman 2002-11-05 18:46:34 UTC
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 13:18:33 UTC
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.