Top showing 9999% CPU usage

Bug #531310 reported by tdn on 2010-03-03
This bug affects 10 people
Affects Status Importance Assigned to Milestone
procps (Ubuntu)

Bug Description

Binary package hint: procps

In the attached screenshot, 'top' is showing 9999% CPU usage for the firefox process. This is not possible.

ProblemType: Bug
Architecture: i386
Date: Wed Mar 3 13:28:18 2010
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: procps 1:3.2.8-1ubuntu3
 PATH=(custom, user)
ProcVersionSignature: Ubuntu 2.6.31-19.56-generic
SourcePackage: procps
Uname: Linux 2.6.31-19-generic i686
XsessionErrors: (polkit-gnome-authentication-agent-1:2629): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

tdn (spam-thomasdamgaard) wrote :
Robert C. Sheets (rcsheets) wrote :

I also saw this, but for the eucalyptus-cloud process, shortly after startup.

Søren Holm (sgh) wrote :

I allso see this sometimes. I'm guessing it is some kind of division by zero or such in top. It only applies to one top-"sample".

Tomasz (Tomek) Muras (zabuch) wrote :

Like the note above: I've seen it for few different processes but always for the top entry in "top". I'm running on 64 bit Ubuntu Desktop 10.04.

Tomasz (Tomek) Muras (zabuch) wrote :
Max Barry (max-maxbarry) wrote :

Seen frequently in 64-bit Ubuntu Server 10.04, usually in an apache2 process.

Related to this?

Max Barry (max-maxbarry) wrote :

Just in case it matters, screenshot of it happening with a defunct process too.

James (james-ellis-gmail) wrote :

Started seeing this after I started using Thunderbird as an email client.

The process is "fuser" and top shows 9999% CPU. General CPU usage rises while 9999% is in use to about 50%.

32bit Kubuntu 11.10

Processor: Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz

James (james-ellis-gmail) wrote :

Cause of fuser going bonkers (for me) is this bug:

That doesn't relate to the erroneous 9999% reporting though.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in procps (Ubuntu):
status: New → Confirmed

It seems that the bug is in the CPU time calculation for the process. Some samples display a smaller time than the previous sample, thus resulting in negative CPU % for that period, which explains the overflow value that appears (9999.0)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers