Bug 149616 - RHEL4: top has screen errors on large smp machines
RHEL4: top has screen errors on large smp machines
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: procps (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
:
Depends On:
Blocks: 156322
  Show dependency treegraph
 
Reported: 2005-02-24 10:05 EST by Daniel W. Ottey
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2005-615
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-05 11:48:47 EDT
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 Daniel W. Ottey 2005-02-24 10:05:12 EST
Description of problem:
On our 32 processor systems (both x86 and ia64), when "top" is used to display
seperate CPU states (by pressing "1"), we sometimes receive a malloc() error:

This problem only occurs when the screen is not large (tall) enough to display
all 32 processors at the same time.  I am pretty sure this problem has been
fixed elsewhere, because it used to happen in SLES8 and no longer occurs in
SLES9.  I was surprised to see it occur in RHEL4.

We also receive a an error when resizing the screen:

*** glibc detected *** realloc(): invalid next size: 0x600000000000d5


Version-Release number of selected component (if applicable):
procps-3.2.1-5.6
Comment 1 Karel Zak 2005-02-24 11:43:32 EST
* Fri Nov  5 2004 Karel Zak <kzak@redhat.com> 3.2.3-6EL
                                              ^^^^^^^
- update FAQ
- update spec description
- fix text in .noproc patch
- fix segv fault if cpu number exceeding 38 (#137159)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*** This bug has been marked as a duplicate of 137159 ***
Comment 2 Daniel W. Ottey 2005-02-24 13:28:20 EST
I am not authorized to read bug 137159.  What is/was its resolution?  You
provide a date of Nov 5, 2004 but this problem exists in the released version of
RHEL4 which was made after that date.  Also note that our system only has 32
processors, not 38, and is still seeing this issue.

Comment 3 Karel Zak 2005-02-24 14:29:15 EST
This problem should be fixed. What version of procps are you use? In your
original report is procps-3.2.1-5.6. But the problem has been fixed in procps >=
3.2.3-6. The number of processor is not important.
Comment 4 Albert Cahalan 2005-02-26 21:52:53 EST
Even the NSA can declassify stuff. Why not Red Hat too?
Ask your security officer to black out stuff as needed,
then stamp DECLASSIFIED on the document, etc.

I don't think any foreign agents will die as a result.
Comment 5 Jay Turner 2005-02-28 02:40:21 EST
RHEL4 shipped with procps-3.2.3-7EL, which includes the fix for the problem you
are seeing.  Do you have one of the RHEL4 betas installed or something, as you
state the version you're seeing the problem on is procps-3.2.1-5.6.

As for bug 137159 being private, that happens from time to time when the bug
reporter includes information which they wish to keep private.  In this
particular case, if we blacked out that type of information you would be left
with a bug which says what kzak already said above . . . problem fixed.

Closing out, as this issue is resolved in the version of procps which shipped
with RHEL4.
Comment 6 Daniel W. Ottey 2005-03-09 08:40:35 EST
My apologies for reporting the incorrect version, as I must have performed my
RPM query on a different machine.  My coworker has verified for me that the
version where the error is being seen is procps-3.2.3-7EL.

I am sorry for the delay in response, as I was out of the office last week.  But
if there is any testing that can be done, we are open to doing so.
Comment 7 Mike Tran 2005-03-10 18:52:27 EST
We encountered this problem on pSeries (32 CPUs) RIT 67597
Comment 8 Karel Zak 2005-03-17 05:56:42 EST
You're right that this bug is there. But it happend all time (for non-SMP too)
if screen is too small.
Comment 9 Karel Zak 2005-03-17 05:59:19 EST

*** This bug has been marked as a duplicate of 149319 ***
Comment 15 Daniel W. Ottey 2005-07-20 10:15:57 EDT
Can a status/update please be provided regarding this bug?  There has been no
status change in over 4 months.
Comment 16 Karel Zak 2005-07-20 10:40:20 EDT
Don't worry:-) It should be fixed in RHEL4-U2.
Comment 17 Daniel W. Ottey 2005-07-20 10:43:01 EDT
Thank you!
Comment 20 Red Hat Bugzilla 2005-10-05 11:48:48 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-615.html

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