Bug 77036
| Summary: | resizing top causes Floating point exception | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Joseph Shraibman <jks> |
| Component: | procps | Assignee: | Daniel Walsh <dwalsh> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | CC: | leonid |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-02-11 13:18:33 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Joseph Shraibman
2002-10-31 05:00:31 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. 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. |