Hide Forgot
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
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.
I just reproduced the bug with ipcs reporting no shared memory (basically this machine hasn't run anything since it was booted)
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...
Maybe because strace floods the connection with data, and this is a timing issue?
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
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
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.
New RPM fixed the problem both with and without "-d0" on 7.2. Thanks.
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.
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.