Version: unspecified (using Devel) OS: Linux The first line which shows init cpu load never stops increasing in 30 seconds, it is at 250%, if I wait it continues climbing Reproducible: Always Steps to Reproduce: launch the app Actual Results: cpu load never ending increasing Expected Results: show the real cpu load
same problem with rc2
Don't suppose you know why? :-) Is there anything unusual about your system at all? And ideas why that could be happening?
I don't know what's happening. standalone kysguard is ok. Top gives me a normal cpu load...
I'm using version 4.7.97 (Kubuntu Pargolin) and experience the same problem. It looks to me that the increase is the actual value it should get. It looks like it computes new_value += load instead of new_value = load. Probably (just guessing) the new load value at every update is computed as the sum of the load of all processes, including init itself.
*** Bug 292037 has been marked as a duplicate of this bug. ***
confirmed with 4.8.0, openSuse 12.1
*** Bug 293357 has been marked as a duplicate of this bug. ***
Confirmed with 4.8.0 ( Slackware current with KDE by Alienbob) Comment #4 is effect I'm seeing, got in early enough after start to watch it climb through 100%, currently past 40,000 and climbing.
*** Bug 295930 has been marked as a duplicate of this bug. ***
Created attachment 70145 [details] wrong CPU usage ksysguard and krunner (Ctrl+Esc) are affected
*** Bug 298129 has been marked as a duplicate of this bug. ***
Confirmed with 4.8.2 (Kubuntu 12.04).
*** Bug 299636 has been marked as a duplicate of this bug. ***
Yes.
confirm with 4.8.3 (OpenSuse 12.1) It appears only if display is set to "All Processes, Tree", for the processes systemd and kthreadd which both are top of the tree. With "All Processes" (no tree), CPU% for those processes is 0.
Confirmed on Ubuntu server with KDE 4.8.3. I suspect there is also a miscalculation with kthreadd, as well as init. e.g. right now kthreadd shows ~17900% and kthreadd shows 145%. kthreadd is rising by 1% each check interval, wheras init rises by something higher (~30% now, with computer essentially idle). Comment #4 seems a valid interpretation of init's rising CPU usage.
Created attachment 71620 [details] Remove parent-id check in order to allow 'init' to be updated. When updating a process, there is a check for the id of its parent. When it is < 0 the update fails. The problem is that (by convention) init and kthreadd have parent -1. Removing the check and relying on QHash<Process*>::value(key) returning Null for a non-existing key fixed the issue. See attachment. hth
> Removing the check and relying on QHash<Process*>::value(key) returning > Null for a non-existing key fixed the issue. See attachment. The 5 lines shown in the diff could simply be changed to this then: Process *parent = d->mProcesses.value(ppid, &d->mFakeProcess);
Thank you very much - I committed this to master and KDE/4.8 I was a total block-head though and didn't say the fix was from you guys in the commit message. Sorry :-( Hopefully this will be in on time for the 4.8.4 release. I used Rolf's one liner change - it would be great if Carlo could actually try this one liner and check that it works. I tried myself, but I could never reproduce the problem anyway. John On 6 June 2012 13:09, Rolf Eike Beer <kde@opensource.sf-tec.de> wrote: > https://bugs.kde.org/show_bug.cgi?id=290687 > > --- Comment #18 from Rolf Eike Beer <kde@opensource.sf-tec.de> --- >> Removing the check and relying on QHash<Process*>::value(key) returning >> Null for a non-existing key fixed the issue. See attachment. > > The 5 lines shown in the diff could simply be changed to this then: > > Process *parent = d->mProcesses.value(ppid, &d->mFakeProcess); > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are watching the assignee of the bug.
> I used Rolf's one liner change - it would be great if Carlo could > actually try this one liner and check that it works. I tried myself, > but I could never reproduce the problem anyway. I can confirm Rolf's change is working for me. The problem was visible only in the "All Processes, Tree" view. thank you.
Thank you again for the fix. And I'm really sorry that I didn't fix myself and left this bug in for so very long.
*** Bug 301344 has been marked as a duplicate of this bug. ***
Setting report status correctly.
Thanks - I don't know if the fix actually got into 4.8.4
I'm running 4.8.4 and yes, the fix did get into the release.
Excellent to hear :-)