This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 78844 - top crashes with Floating point exception
top crashes with Floating point exception
Status: CLOSED DUPLICATE of bug 67200
Product: Red Hat Linux
Classification: Retired
Component: procps (Show other bugs)
7.2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-01 19:28 EST by John Newbigin
Modified: 2007-04-18 12:48 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-12-01 19:28:12 EST
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 John Newbigin 2002-12-01 19:28:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826

Description of problem:
top prints out the first few summary lines and then zero, one or two cpu status
lines and then prints Floating point exception and exits.

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


How reproducible:
Sometimes

Steps to Reproduce:
It is happening every time on the box in question now, but it used to work.

When I run with strace, it does not crash.

Actual Results:  Run1:
 11:21am  up 286 days, 17:50,  4 users,  load average: 0.03, 0.19, 0.56
203 processes: 200 sleeping, 1 running, 1 zombie, 1 stopped
Floating point exception

Run2:
 11:21am  up 286 days, 17:50,  4 users,  load average: 0.08, 0.19, 0.55
203 processes: 200 sleeping, 1 running, 1 zombie, 1 stopped
CPU0 states: 15.0% user, 84.0% system,  0.0% nice,  0.0% idle
Floating point exception

etc.

Expected Results:  Normal top output

Additional info:

When I run top with strace, it works but the system CPU usage looks wrong.

 11:24am  up 286 days, 17:53,  4 users,  load average: 0.08, 0.15, 0.47
204 processes: 201 sleeping, 1 running, 1 zombie, 1 stopped
CPU0 states: 16.0% user, 83.0% system,  0.0% nice,  0.0% idle
CPU1 states: 16.0% user, 83.0% system,  0.0% nice,  0.0% idle
CPU2 states: 50.0% user, 50.0% system,  0.0% nice,  0.0% idle
CPU3 states: 12.0% user, 87.0% system,  0.0% nice,  0.0% idle
Mem:  2574644K av, 2562656K used,   11988K free, 1329716K shrd,  122316K buff
Swap: 2097112K av, 1065336K used, 1031776K free                  470396K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
31648 jnewbigi  10   0   572  572   456 S    24.0  0.0   0:01 strace
31649 jnewbigi  11   0  1124 1120   828 R    24.0  0.0   0:00 top
    1 root       8   0   376  336   316 S     0.0  0.0   1:31 init
    2 root       9   0     0    0     0 SW    0.0  0.0   0:00 keventd
    3 root      19  19     0    0     0 SWN   0.0  0.0   0:36 ksoftirqd_CPU0
    4 root      19  19     0    0     0 SWN   0.0  0.0   0:37 ksoftirqd_CPU1
    5 root      19  19     0    0     0 SWN   0.0  0.0   0:36 ksoftirqd_CPU2
    6 root      19  19     0    0     0 SWN   0.0  0.0   0:36 ksoftirqd_CPU3
    7 root       9   0     0    0     0 SW    0.0  0.0 209:01 kswapd
    8 root       9   0     0    0     0 SW    0.0  0.0   0:01 kreclaimd
    9 root       9   0     0    0     0 SW    0.0  0.0   0:00 bdflush
   10 root       9   0     0    0     0 SW    0.0  0.0   5:13 kupdated
   11 root      -1 -20     0    0     0 SW<   0.0  0.0   0:00 mdrecoveryd
   20 root       9   0     0    0     0 SW    0.0  0.0   9:47 kjournald
Comment 1 Alexander Larsson 2002-12-02 05:07:15 EST

*** This bug has been marked as a duplicate of 67200 ***

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