Bug 273214

Reproducible on archlinux x86_64 with KDE 4.6.3.

Is it with a default desktop setting? No added applets?
I run my desktop for days so I am curious about this, is it a new user? If not, what applets do you have running? Shridhar, Oded, please elaborate on what's going on? Can you reproduce with a new user?

As far as applets go, I have system tray and a clock in panel. The desktop has mini player and absolutely nothing else, no folder view, no activities.

I am adding a new user and I will keep running its session in the background and check if it happens in couple of days.

 I wouldn't be surprised if it does not happen with the new user. My current ~/.kde/~/.kde4 were refreshed circa 4.1 or so I think.

Addtionally, I usually suspend my desktop  and reboot very rarely. That could be an aspect influencing this bug.

I have a few widgets - nothing very fancy:
Panel: kickoff, smooth tasks, pager, CPU monitor, notification area, clock.
Desktop - 1 activity: Folder view, network manager, battery monitor.

As a side note - if this problem is reproduceable only with some widgets, it is still a problem: the whole point if the plasma desktop is that you can add all kinds of widgets, and I'd still expect the desktop not to eat up all my CPU.

Oded: of course you can add widgets but some of them are third party ones (like smooth tasks) and maybe not up-up-date with your current distribution that's why I am asking you to check with a new user and with a default desktop shipped by KDE. Then you can start adding applets in order to check if one triggers the bug.

Shridhar, thanks for your test!

One thing I noticed going over the thread is fedora 15 uses systemd and I am running systemd as well on arch-linux which is my default boot now. 

Also I am running a CPU monitor in panel, which I didn't realize was a widget earlier.

Yesterday evening I hit the bug again and I attached gdb to plasma desktop and got following backtrace in one of the threads(rest of the two threads are sleeping in poll/select).

(gdb) bt
#0  0x00007f481064cdf5 in KSGRD::SensorAgent::sendRequest(QString const&, KSGRD::SensorClient*, int) () from /usr/lib/libksgrd.so.4
#1  0x00007f481064eef2 in KSGRD::SensorManager::sendRequest(QString const&, QString const&, KSGRD::SensorClient*, int) ()
   from /usr/lib/libksgrd.so.4
#2  0x00007f481085f8bd in ?? () from /usr/lib/kde4/plasma_engine_systemmonitor.so
#3  0x00007f481064d158 in KSGRD::SensorAgent::processAnswer(char const*, int) () from /usr/lib/libksgrd.so.4
#4  0x00007f4810655b2e in ?? () from /usr/lib/libksgrd.so.4
#5  0x00007f4810656468 in ?? () from /usr/lib/libksgrd.so.4
#6  0x00007f483417929a in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4
#7  0x00007f483410aa5b in ?? () from /usr/lib/libQtCore.so.4
#8  0x00007f483410b719 in QProcess::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libQtCore.so.4
#9  0x00007f483482ed38 in KProcess::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libkdecore.so.5
#10 0x00007f483417929a in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4
#11 0x00007f48341c28de in QSocketNotifier::activated(int) () from /usr/lib/libQtCore.so.4
#12 0x00007f4834180f4b in QSocketNotifier::event(QEvent*) () from /usr/lib/libQtCore.so.4

Today morning, I got the 100% cpu usage again but this time the backtrace is not the same. In strace, plasma-desktop is stating /etc/localtime like crazy.

When it is not stating /etc/localtime, following is the strace of plasma-desktop. The first and last stats are included to mark the boundary of activity.

-----------------
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=265, ...}) = 0
read(8, "\34\0;\25\36\0\300\2;\1\0\0\225\274<\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 448
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=13, events=POLLIN}, {fd=21, events=POLLIN}, {fd=23, events=POLLIN}, {fd=29, events=POLLIN}, {fd=27, events=POLLIN}, {fd=19, events=POLLIN}, {fd=20, events=POLLOUT}], 13, 0) = 1 ([{fd=20, revents=POLLOUT}])
write(20, "acpi/Cooling_Device/0/Current St"..., 4080) = 4080
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=265, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=265, ...}) = 0
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"\24\0\6\0\36\0\300\2\20\1\0\0\20\1\0\0\0\0\0\0\1\0\0\0", 24}, {NULL, 0}, {"", 0}], 3) = 24
poll([{fd=8, events=POLLIN}], 1, -1)    = 1 ([{fd=8, revents=POLLIN}])
read(8, "\1 <\25\1\0\0\0\20\1\0\0\4\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 36
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"\24\0\6\0\36\0\300\0022\1\0\0\4\0\0\0\0\0\0\0\0\10\0\0", 24}, {NULL, 0}, {"", 0}], 3) = 24
poll([{fd=8, events=POLLIN}], 1, -1)    = 1 ([{fd=8, revents=POLLIN}])
read(8, "\1 =\25\2\0\0\0\4\0\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 40
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"\24\0\6\0\36\0\300\2\224\1\0\0\6\0\0\0\0\0\0\0\1\0\0\0", 24}, {NULL, 0}, {"", 0}], 3) = 24
poll([{fd=8, events=POLLIN}], 1, -1)    = 1 ([{fd=8, revents=POLLIN}])
read(8, "\1 >\25\1\0\0\0\6\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 36
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"\24\0\6\0\36\0\300\2-\1\0\0W\1\0\0\0\0\0\0\240\206\1\0", 24}, {NULL, 0}, {"", 0}], 3) = 24
poll([{fd=8, events=POLLIN}], 1, -1)    = 1 ([{fd=8, revents=POLLIN}])
read(8, "\1\10?\25\4\0\0\0W\1\0\0\0\0\0\0\17\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 48
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"\24\0\6\0\36\0\300\2\222\1\0\0W\1\0\0\0\0\0\0\240\206\1\0", 24}, {NULL, 0}, {"", 0}], 3) = 24
poll([{fd=8, events=POLLIN}], 1, -1)    = 1 ([{fd=8, revents=POLLIN}])
read(8, "\1\0@\25\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"\24\0\6\0\36\0\300\2>\1\0\0\4\0\0\0\0\0\0\0\0\10\0\0", 24}, {NULL, 0}, {"", 0}], 3) = 24
poll([{fd=8, events=POLLIN}], 1, -1)    = 1 ([{fd=8, revents=POLLIN}])
read(8, "\1 A\25\1\0\0\0\4\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 36
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"\24\0\6\0\36\0\300\2\232\1\0\0\4\0\0\0\0\0\0\0\0\10\0\0", 24}, {NULL, 0}, {"", 0}], 3) = 24
poll([{fd=8, events=POLLIN}], 1, -1)    = 1 ([{fd=8, revents=POLLIN}])
read(8, "\1 B\25\7\0\0\0\4\0\0\0\0\0\0\0\7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 60
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"\24\0\6\0\36\0\300\2D\0\0\0!\0\0\0\0\0\0\0\1\0\0\0", 24}, {NULL, 0}, {"", 0}], 3) = 24
poll([{fd=8, events=POLLIN}], 1, -1)    = 1 ([{fd=8, revents=POLLIN}])
read(8, "\1\0C\25\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"\16\0\2\0\36\0\300\2", 8}, {NULL, 0}, {"", 0}], 3) = 8
poll([{fd=8, events=POLLIN}], 1, -1)    = 1 ([{fd=8, revents=POLLIN}])
read(8, "\1 D\25\0\0\0\0\257\0\0\0\0\0\0\0P\5\314\2\0\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"(\0\4\0\36\0\300\2\257\0\0\0\0\0\0\0", 16}, {NULL, 0}, {"", 0}], 3) = 16
poll([{fd=8, events=POLLIN}], 1, -1)    = 1 ([{fd=8, revents=POLLIN}])
read(8, "\1\1E\25\0\0\0\0a\1\200\1\0\0\31\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=265, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=265, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=265, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=265, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=265, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=265, ...}) = 0
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"\225\7\2\0\211&\341\0016\0\2\0\210&\341\1", 16}, {NULL, 0}, {"", 0}], 3) = 16
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=13, events=POLLIN}, {fd=21, events=POLLIN}, {fd=23, events=POLLIN}, {fd=29, events=POLLIN}, {fd=27, events=POLLIN}, {fd=19, events=POLLIN}, {fd=20, events=POLLOUT}], 13, 0) = 2 ([{fd=21, revents=POLLIN}, {fd=20, revents=POLLOUT}])
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"\225\10\t\0\1&\341\1\302\21\340\1\0\0\0\0\30\1\340\1\0\0\0\0P\5\33\0N\0\2\0"..., 912}, {NULL, 0}, {"", 0}], 3) = 912
poll([{fd=8, events=POLLIN}], 1, -1)    = 1 ([{fd=8, revents=POLLIN}])
read(8, "\1\0y\25\0\0\0\0 \0\200\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{";\3\5\0\321&\341\1\0\0\0\0N\0\2\0&\1\31\0\225\6\5\0\30\1\340\1\0\0\0\0"..., 956}, {NULL, 0}, {"", 0}], 3) = 956
poll([{fd=8, events=POLLIN}], 1, -1)    = 1 ([{fd=8, revents=POLLIN}])
read(8, "\1 \244\25D\21\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096
read(8, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 13616) = 13616
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"5\30\4\0\331&\341\1\257\0\0\0\4\1\21\0\225\4\5\0\332&\341\1\331&\341\1*\0\0\0"..., 376}, {"\3\3\3\3\7\7\7\7\7\7\7\7\6\6\6\6\3\3\3\3\1\1\1\1\1\1\1\1\1\1\1\1"..., 17680}, {"", 0}], 3) = 18056
ioctl(21, FIONREAD, [41])               = 0
read(21, "\33RECONFIGURE\33UNKNOWN COMMAND\nksy"..., 41) = 41
write(20, "disk/sdb_(8:16)/Rate/wblk?\ndisk/"..., 4067) = 4067
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"<\30\2\0\341&\341\1\225\10\t\0\3\1\21\0\340&\341\1\0\0\0\0\334&\341\1\0\0\0\0"..., 360}, {NULL, 0}, {"", 0}], 3) = 360
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=13, events=POLLIN}, {fd=21, events=POLLIN}, {fd=23, events=POLLIN}, {fd=29, events=POLLIN}, {fd=27, events=POLLIN}, {fd=19, events=POLLIN}, {fd=20, events=POLLOUT}], 13, 0) = 2 ([{fd=21, revents=POLLIN}, {fd=20, revents=POLLOUT}])
read(8, 0x1af4714, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
ioctl(21, FIONREAD, [2384])             = 0
read(21, "UNKNOWN COMMAND\nksysguardd> Numb"..., 2384) = 2384
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=265, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=265, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=265, ...}) = 0
-----------------

(In reply to comment #6)
> Today morning, I got the 100% cpu usage again but this time the backtrace is
> not the same. In strace, plasma-desktop is stating /etc/localtime like crazy.

This is also the behavior that I'm seeing.

(In reply to comment #7)
> (In reply to comment #6)
> > Today morning, I got the 100% cpu usage again but this time the backtrace is
> > not the same. In strace, plasma-desktop is stating /etc/localtime like crazy.
> 
> This is also the behavior that I'm seeing.

In the test account's default plasma desktop I don't see this behavior. So I removed the CPU monitor widget and now I no longer see this behavior in my own desktop. I'll check how it behaves tomorrow (which usually should be enough time to trigger the behavior) but I feel this may be the issue.

After the cpu monitor is removed, the bug is no longer reproducible. A full day of computer usage did not show the bug and the desktop is snappy like never before.

I have not experienced the problematic behavior after using plasma desktop for about a day, so it seems the problematic widget is CPU monitor.

I have updated the bug's summary accordingly.

just to make sure, do you have the microblog widget somewhere?

No, I do not use the micro-blogging widget.

I see similar bug when using memory monitor widget and temperature widget, I suspect all widget use the ksysguard data engine are affected, plasma slows down dramatically and I get 0's in those monitor: 0 cpu usage, 0 memory usage, 0 hardware temperatures (I update the info every 10s)

I see the same behaviour using Fedora 15 and KDE 4.6.3.  I'm using the CPU, disk space, and network monitor widgets, as well as some other (non-ksysguard) widgets.  Renaming ~/.kde and logging in again fixes the problem.  Restoring ~/.kde and logging in again brings the problem back.

Although the problem doesn't become obvious for about 12 hours, I can see it within a few minutes by looking at the plasma-desktop process's CPU time.

I am seeing the same thing with Fedora 15 (fully patched) with plain KDE and just the CPU monitor widget added. Remove the widget and all is good again. With CPU monitor, CPU usage increases to 100% after about 20 hr. Reproducible.

FYI: Fedora Bugzilla entry for this problem <https://bugzilla.redhat.com/show_bug.cgi?id=710918>

marking confirmed, I think we have enough "me too's"

Debian bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627101

I only experience this bug in Debian with systemd installed (25-2 from experimental). Reverting back to sysvinit appears to solve the issue for me.

Also manifests on Gentoo, KDE 4.7.0. I'm using most of the widgets mentioned above: disk space, memory, CPU, network and temperature monitors.

The process enters the endless fstat("/etc/localtime", ...) loop after about half an hour of runtime here, sometimes even sooner. The readings in the widgets appear to drop from the beginning though, even before the loop begins.

confirmed on Gentoo, 4.7.2, experienced with cpu and network monitor widgets. takes about 10 minutes to become noticable, seems to accumulate over time until it reaches 100% load.

I think the bug is gone in the 4.7 branch of kdelibs + master kdebase. I have not see  high cpu usage related to plasma in a few weeks.

Looks like this bug has just awaken from hibernation in 4.8.0. I've been experiencing this bug on daily basis. A GDB backtrace would reveal the exact same output as the previous comments. I have a CPU Monitor widget placed on the desktop.

I can confirm this behaviour on a Gentoo build of KDE 4.8.4.  Plasma settings are all default but for the "System Load Viewer" widget added to the panel.  CPU load will tend to spike after about a day or so and plasma will be completely unresponsive until killed and restarted.  This system does not have systemd, either; I think that's a red herring.

One other detail-- when it goes out of control, it sometimes disappears from the bar.  Reviving plasma after killing it sometimes causes some bars of the load viewer to "flicker" in and out seemingly at random. (This may be a separate bug).

Confirm on Ubuntu 12.04 amd64, KDE 4.8.4.
When adding "CPU monitoring" widget, plasma-desktop becomes very slow after some hours.

Confirmed again on Ubuntu 12.04 amd64, KDE 4,8,4. It takes about 5-6 hours for the desktop to become slow and inresponcive. I used CPU, memory and network widgets all at once.

See that at kde 4.10.1, befor - never seen. As writed before, sysprof say KSGRD::SensorAgent::sendRequest load cpu. From widgets, have only cpu monitor, and default plasma panel+right panel width icons.

http://ompldr.org/vaG9iOQ

archlinux, x64, nvidia, 3.8 kernel

I can reproduce this almost instantly even without the monitor widgets. the stat(/etc/localtime) stuff does not only eat CPU, but also leaks memory. RSS of the plasma-desktop process grows steadily while the /etc/locatime file is stat'ed. It grows over 1GiB in less than 1 hour.

I catched backgrace of the thread performing the stat:
#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 ()

After resetting plasma configuration the issue "magically" disappeared. I might have been caused by some crazy widget - but I am using the same set of widgets now.

This bug is confirmed on KDE 4.11.5 with kernel 3.12.21-gentoo-r1.

An strace of the running plasma-desktop process while it consumes 100% CPU shows repeated calls to stat() on /etc/localtime. As soon as I close my monitoring widgets, the abnormal CPU usage stabilizes. Willing to perform any other tests which may be needed to help gather additional details.

(In reply to James Lott from comment #29)
Seeing the same thing on Debian jessie (plasma-desktop 4:4.11.11-1.) CPU use rises slowly after restarting plasma-desktop until is becomes quite unresponsive. I see the same accesses to /etc/localtime.

Created attachment 88391 [details]
Ksysguard CPU graph after restarting plasma-desktop on a mostly idle system

After running for a few minutes it looks like this:
Tasks: 319 total,   3 running, 316 sleeping,   0 stopped,   0 zombie
%Cpu(s): 18.2 us,  1.3 sy,  0.0 ni, 80.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  16412920 total, 16233460 used,   179460 free,   141628 buffers
KiB Swap: 33371132 total,        0 used, 33371132 free. 10577844 cached Mem
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                         
18729 rrohbeck  20   0 3319304 172764  87940 R  84.5  1.1   3:45.13 plasma-desktop                                                                         
24006 root      20   0  758176 246972 117040 S  39.1  1.5  29:35.66 Xorg                                                                            18766 rrohbeck  20   0  456256  49260  31016 S   9.6  0.3   1:13.83 ksysguard

(In reply to Ralf-Peter Rohbeck from comment #31)
Still happening after a reboot and running nothing but konsole.

(In reply to Ralf-Peter Rohbeck from comment #32)
This was caused by the System Monitor widget. After removing it from my panel the problem disappeared.

It seems I am hitting this running kde 4.13.3 on am64 gentoo.  I have never had this issue (and always ran the CPU monitor), but for the past 2 weeks my cpu usage will eventually hit 100% for plasma-desktop.

If I kill/restart plasma-desktop  the problem goes away but comes back after a while.  If I delete/re-add the CPU monitor the same thing.

I did notice that around the time this started happening, I had upgraded the timezone-data package (which updates /etc/localtime, the file people previously talked about being indicative of the problem).

Well, I don't know if this will help but I "fixed" my 100% cpu usage issue like this.  I recalled that since I started noticing the problem, I had changed some settings in my digital clock applet, related to showing only Canada holidays (and maybe some other things).

I had an old backup of my .kde4 dir so I diffed them, and changed the following three things back, and now the 100% cpu issue is gone (might be related to the /etc/localtime being repeatedly hit in peoples reports of strace).

in .kde4/share/config/plasma-desktop-appletsrc I changed these three things in the (I assume) digital clock section:

< calendarType=-1
> calendarType=locale

< holidaysRegions=ca_en-gb
> holidaysRegions=

< timeZones=UTC
> timeZones=

I'm not sure which one fixed it, but a developer might.

(In reply to Dave Flogeras from comment #35)
I have several time zones enabled in my Digital Clock applet (home is PST; added Adelaide, Berlin, Denver and UTC.) No changes to the calendar or holiday settings.

This could be a duplicate of bug 336551. Can someone confirm 4.14 fixes it?

(In reply to Christoph Feck from comment #37)
> This could be a duplicate of bug 336551. Can someone confirm 4.14 fixes it?

Fixed in a freshy updated Debian jessie system (kdelibs 4.14.1-1+b1). Thanks!

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

I  thought I would add clue or 2 on thjis since I ran into the same or similar issue as is described throughout this thread. I had went through synaptic yesterday and installed a bunch of widgets listed within the package manager after doing a search of all using 'widget' as a keyword. 

After  installing the widgets I noticed that the longer I stayed logged in to KDE Plasma the 'plasma-desktop' process started to eat up CPU, in system monitor it would consistently spike just like Ralf-Peter's graph. If I logged out of KDE and logged back in it would give back the memory and, at first, it would not spike  CPU use in system monitor. If I logged into Cinnamon the problem would not appear.

I installed these files in Syanaptic, after I went through and removed all of them the problem has went away. I still have my SuperKaramba monitors running like before and all is well again. I thought I would throw this list of packages up that I removed to get rid of the problem. I apologize for not going through and uninstalling one-by-one and getting the exact culprit, but at least we know it is   coming from the official repositories, because that was where I pulled the widgets from. I  had NOT actually put the widgets into use on the desktop, so apparently all you need to do is pull from the official repositories to create the problem.

Removed the following packages:
itk3
iwidgets4
iwidgets4-doc
kde-style-qtcurve
kwin-style-qtcurve
libgladeui-2-6
libgladeui-common
libktpwidgetsprivate7
libqt5core5a
libqt5dbus5
libqt5gui5
libqt5network5
libqt5test5
libqt5websockets5
libqt5x11extras5
plasma-nm-dbg
plasma-widget-adjustableclock
plasma-widget-ktorrent
plasma-widget-menubar
plasma-widget-networkmanagement-dbg
plasma-widget-veromix
plasma-widget-yawp
plasma-widget-yawp-dbg
qttranslations5-l10n

Removed the following packages:
appmenu-qt
itcl3
kde-telepathy-kpeople
ktorrent
ktorrent-data
ladspa-sdk
libfftw3-3
libfftw3-long3
libkpeople3
libktpcommoninternalsprivate7
libktpmodelsprivate7
libqtglib-2.0-0
libtelepathy-logger-qt4-1
libtelepathy-logger3
libtelepathy-qt4-2
swh-plugins
veromix-common