Bug 292037 - ksysguard counts up to thousands of CPU usage percentage for the init process
Summary: ksysguard counts up to thousands of CPU usage percentage for the init process
Status: RESOLVED DUPLICATE of bug 290687
Alias: None
Product: ksysguard
Classification: Applications
Component: ksysguard (show other bugs)
Version: unspecified
Platform: Chakra Linux
: NOR normal
Target Milestone: ---
Assignee: KSysGuard Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-20 14:28 UTC by Daniele Cocca
Modified: 2012-01-26 16:09 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Live screenshot of the ksysguard fail. (99.65 KB, image/png)
2012-01-20 14:28 UTC, Daniele Cocca
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniele Cocca 2012-01-20 14:28:32 UTC
Created attachment 68038 [details]
Live screenshot of the ksysguard fail.

Version:           unspecified (using Devel) 
OS:                Linux

When I fire up ksysguard and choose the "process tree" view, I can see the CPU usage percentage for the init process is a normal one, usually not more than 30%-40%, but if I leave ksysguard open, it easily goes up to several thousands of percentage. I'm attaching a screenshot that shows this behavior.

Reproducible: Always

Steps to Reproduce:
Open ksysguard, select process tree view, order by CPU usage, leave it open for a couple of minutes.

Actual Results:  
Thousands of CPU usage percentage reported. Attached screenshot shows more than 10000%.

Expected Results:  
Actual CPU usage is shown.

From a quick look, it seems like at each step the new CPU usage percentage is added to the old one, instead of simply replacing it.
Comment 1 Jessie A. Morris 2012-01-25 22:21:01 UTC
I too am having this issue. I'm on Kubuntu 11.04 using 4.8 RC2 from one of the PPA's. I have to agree, it does appear to be adding up the CPU usage rather than replacing. Could someone mark this as confirmed?
Comment 2 Christoph Feck 2012-01-26 16:09:32 UTC

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