Bug 727597 - Plasma-desktop eat my CPU
Summary: Plasma-desktop eat my CPU
Alias: None
Product: Fedora
Classification: Fedora
Component: kde-workspace
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Ngo Than
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-02 14:48 UTC by Pavel Alexeev
Modified: 2015-02-17 13:49 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-02-17 13:49:59 UTC

Attachments (Terms of Use)

Description Pavel Alexeev 2011-08-02 14:48:44 UTC
Description of problem:
plasma-desktop process always eat about 50-80% of my CPU:

# top -p `pidof plasma-desktop` -b -n1
top - 18:24:56 up  7:07,  8 users,  load average: 1.81, 1.81, 1.77
Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
Cpu(s): 23.4%us, 37.8%sy,  0.0%ni, 29.1%id,  4.5%wa,  0.0%hi,  5.2%si,  0.0%st
Mem:   1026268k total,   951976k used,    74292k free,     3764k buffers
Swap:  2031612k total,   313320k used,  1718292k free,   126856k cached

  PID USER      NI  VIRT  RES SWAP  SHR S %CPU %MEM    TIME+   PPID COMMAND                                                                                     
 1513 pasha      0  321m  24m 6844 9364 R 71.9  2.5 155:04.55     1 /usr/bin/plasma-desktop

Version-Release number of selected component (if applicable):
# rpm -qa '*kde*'

With hope it may help I had upgrade KDE stuff to rawhide wersions, but on Fedora 15 it also was reproduced.

How reproducible:

Comment 1 Stan Showers 2011-09-19 17:56:18 UTC
Reporting similar problem with plasma-desktop and Fedora 15:
If Dell Laptop is left on overnight plasma-desktop is consuming ~92% CPU in the morning.  The following 
kquitapp plasma-desktop && sleep 10s && plasma-desktop &
brings the CPU usage down to ~3% and the system okay for the rest of the work day.
When the plasma-desktop is using high CPU, there is plenty of RAM free (~500M) and disc activity is negligible.  Had been using Fedora 13 since its release with no such problems.
One thing that is different using Fedora 15 on my system is the behaviour of the external monitor.  With the laptop lid closed the ATI Mobility Radeon x600 seems to be driving a resolution of 1920x1200 to the external monitor and some of the display is then not physically viewable.  My work around is to tell "Configure Display" that the laptop LVDS display is 1600x1200 (which it is not, it is actually 1920x1200 but the lid is closed so shouldn't hurt anything right?).  Then the 1600x1200 external monitor displays correctly.  The only other thing that is weird about my system and Fedora 15 is that the login manager does not display on the external monitor - the wallpaper is there, just no login field.  I blindly type in my password, hit enter, do the "Configure Display" hocus pocus and I'm good to work for several hours with performance not too much worse than Fedora13.

Comment 2 Stan Showers 2011-09-20 15:18:22 UTC
For me, removing the following widgets from the system tray solved the plasma-desktop consuming all the CPU problem:
CPU Monitor
Memory Status
Network Monitor

Comment 3 Travis Sidelinger 2011-10-19 12:06:03 UTC
I have the same issue.

An strace of plasma-desktop shows thousands of stat requests per second:

[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}q) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
[pid  1934] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0

Comment 4 Paul Johnson 2011-11-05 10:34:03 UTC
I have this one too.  At least part of the problem is using the Network Manager to monitor bandwidth.

1: Run "top" in a shell window.  Observe that plasma-desktop is quiescent.

2: In the System Tray click the Network Monitor, then click an active interface to show the bandwidth graph.

3: Observe on "top" that plasma-desktop is now consuming 100% of a CPU (on multi-core systems this will be shown as a percentage of total CPU capacity).  This continues even when the System Tray bandwidth graph is not visible.

4: Click the "Go Back" arrow at the top of the network interface details to close the bandwidth graph.

5: Observe on "top" that the plasma-desktop is quiescent once more.

Comment 5 Fedora End Of Life 2013-04-03 17:50:25 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:

Comment 6 Martin Kyral 2013-11-18 15:05:00 UTC
I am hit by this issue with kde-workspace-4.11.3-1.fc19.x86_64.

In my case, plasma-desktop starts reading /etc/localtime in a loop few minutes after being (re)started. From time to time, it stops doing that. It does not only eat CPU, it also seems to be the cause of a memory leak (when performing stat /etc/localtime wildly, RSS slowly grows, when there's not the stat, RSS seems to be stable).
I catched the backtrace of the responsible thread:

#0  0x0000003fe3ee6f75 in __GI___xstat (vers=<optimized out>, name=0x3fe3f7bf64 "/etc/localtime", buf=0x7fff67e02a00) at ../sysdeps/unix/sysv/linux/wordsize-64/xstat.c:37
#1  0x0000003fe3eaf566 in __tzfile_read (file=file@entry=0x3fe3f7bf64 "/etc/localtime", extra=extra@entry=0, extrap=extrap@entry=0x0) at tzfile.c:170
#2  0x0000003fe3eae894 in tzset_internal (always=always@entry=1, explicit=explicit@entry=1) at tzset.c:444
#3  0x0000003fe3eaf1c0 in __tzset () at tzset.c:597
#4  0x0000003febe892c0 in QTime::currentTime () at tools/qdatetime.cpp:3116
#5  0x0000003010570280 in Plasma::SignalRelay::checkAlignment (this=this@entry=0x3d349e0) at /usr/src/debug/kdelibs-4.11.3/plasma/private/datacontainer_p.cpp:89
#6  0x0000003010570798 in Plasma::SignalRelay::timerEvent (this=0x3d349e0, event=<optimized out>) at /usr/src/debug/kdelibs-4.11.3/plasma/private/datacontainer_p.cpp:151
#7  0x0000003febf92141 in QObject::event (this=0x3d349e0, e=<optimized out>) at kernel/qobject.cpp:1156
#8  0x0000003fef1c84dc in QApplicationPrivate::notify_helper (this=this@entry=0x2016920, receiver=receiver@entry=0x3d349e0, e=e@entry=0x7fff67e02f50) at kernel/qapplication.cpp:4562
#9  0x0000003fef1ceaa0 in QApplication::notify (this=this@entry=0x2013180, receiver=receiver@entry=0x3d349e0, e=e@entry=0x7fff67e02f50) at kernel/qapplication.cpp:4348
#10 0x0000003016a3fe9a in KApplication::notify (this=0x2013180, receiver=0x3d349e0, event=0x7fff67e02f50) at /usr/src/debug/kdelibs-4.11.3/kdeui/kernel/kapplication.cpp:311
#11 0x0000003febf7a26d in QCoreApplication::notifyInternal (this=0x2013180, receiver=0x3d349e0, event=0x7fff67e02f50) at kernel/qcoreapplication.cpp:949
#12 0x0000003febfa9c13 in sendEvent (event=<optimized out>, receiver=<optimized out>) at kernel/qcoreapplication.h:231
#13 QTimerInfoList::activateTimers (this=0x1ff3e10) at kernel/qeventdispatcher_unix.cpp:621
#14 0x0000003febfa6f11 in timerSourceDispatch (source=source@entry=0x1ff3db0) at kernel/qeventdispatcher_glib.cpp:186
#15 0x0000003fe7647e06 in g_main_dispatch (context=0x2016cb0) at gmain.c:3054
#16 g_main_context_dispatch (context=context@entry=0x2016cb0) at gmain.c:3630
#17 0x0000003fe7648158 in g_main_context_iterate (context=context@entry=0x2016cb0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3701
#18 0x0000003fe76481fc in g_main_context_iteration (context=0x2016cb0, may_block=1) at gmain.c:3762
#19 0x0000003febfa7145 in QEventDispatcherGlib::processEvents (this=0x1f7f240, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#20 0x0000003fef264fc6 in QGuiEventDispatcherGlib::processEvents (this=<optimized out>, flags=...) at kernel/qguieventdispatcher_glib.cpp:207
#21 0x0000003febf78ecf in QEventLoop::processEvents (this=this@entry=0x7fff67e031d0, flags=...) at kernel/qeventloop.cpp:149
#22 0x0000003febf791c5 in QEventLoop::exec (this=this@entry=0x7fff67e031d0, flags=...) at kernel/qeventloop.cpp:204
#23 0x0000003febf7e45b in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1221
#24 0x0000003fef1c6c9c in QApplication::exec () at kernel/qapplication.cpp:3823
#25 0x000000300043c40c in kdemain (argc=2, argv=0x7fff67e03428) at /usr/src/debug/kde-workspace-4.11.3/plasma/desktop/shell/main.cpp:126
#26 0x0000003fe3e21b45 in __libc_start_main (main=0x400940 <main(int, char**)>, argc=2, ubp_av=0x7fff67e03428, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff67e03418) at libc-start.c:274
#27 0x0000000000400971 in _start ()

Comment 7 Rex Dieter 2013-11-18 15:18:40 UTC
Thanks, what does your /etc/localtime point to?

ls -l /etc/localtime

Comment 8 Martin Kyral 2013-11-18 15:24:27 UTC
lrwxrwxrwx. 1 root root 35 Jan  3  2013 /etc/localtime -> ../usr/share/zoneinfo/Europe/Prague

Comment 9 Martin Kyral 2013-11-18 15:40:31 UTC
Just to be more specific: "slowly grows" means in my case that the plasma-desktop RSS grows over 1GiB in less than 1 hour. So, it's not that slow..

Comment 10 Pavel Alexeev 2013-11-22 08:48:54 UTC
I also experience gigantic memory leak when plasma-desktop grow up to ~4Gb in memory yesterday.

Comment 11 Martin Kyral 2013-11-22 13:22:55 UTC
Hmm, so I "fixed" the issue by wiping plasma cfg out and letting plasma-desktop to create new one (and spending some time to configure it according my taste again). Probably the cause was some mad applet - don't know which as now I use the same set of widgets with no problem.

However, I kept the old configuration for the purpose of testing, if needed.

Comment 12 Fedora End Of Life 2015-01-09 16:44:27 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 13 Fedora End Of Life 2015-02-17 13:49:59 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

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