Bug 337674 - kded5 is eating CPU
Summary: kded5 is eating CPU
Status: VERIFIED FIXED
Alias: None
Product: Powerdevil
Classification: Unclassified
Component: general (show other bugs)
Version: 5.2.0
Platform: Kubuntu Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Development Mailing List
URL:
Keywords:
: 341775 343542 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-07-21 15:23 UTC by Ruman Gerst
Modified: 2016-03-27 02:27 UTC (History)
39 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.2.1


Attachments
Performance analysis created by sudo sysprof (1.43 MB, text/plain)
2014-07-21 15:23 UTC, Ruman Gerst
Details
xsession-errors file (1.32 MB, text/x-log)
2014-07-22 21:53 UTC, NForce
Details
gdb bt output (31.40 KB, text/plain)
2014-08-20 22:00 UTC, Adrian Rocha
Details
GDB output as requested (4.34 KB, text/plain)
2014-08-27 17:54 UTC, kdeuser56
Details
sligthly more debug (15.95 KB, text/plain)
2015-01-13 02:09 UTC, Hrvoje Senjan
Details
Output from sudo sysprof now with Plasma 5.2 [Kubuntu Next Backports] (526.42 KB, text/plain)
2015-01-28 23:54 UTC, Ruman Gerst
Details
gdb trace of kded5 5.6.0-0ubuntu1 (51.40 KB, text/plain)
2015-01-30 12:50 UTC, Jürgen Scholz
Details
kded5 cpu usage (3.70 KB, image/png)
2015-12-16 07:32 UTC, miflab
Details
thread apply all bt (3.20 KB, text/plain)
2015-12-16 07:34 UTC, miflab
Details
bt (3.14 KB, text/plain)
2015-12-29 16:58 UTC, miflab
Details
screenshot (20.89 KB, image/png)
2016-01-09 22:50 UTC, miflab
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ruman Gerst 2014-07-21 15:23:09 UTC
Created attachment 87860 [details]
Performance analysis created by sudo sysprof

I'm currently running Plasma 5 on Kubuntu (Neon PPA) and I noticed that kded5 (child of kdeinit5) is eating 25% of my CPU (4 cores), after using Plasma 5 a while.

I created a file with sysprof - maybe it helps to identify the problem.
Comment 1 Christoph Feck 2014-07-22 03:52:05 UTC
Could you check which kded module is responsible? You can move individual modules away from /usr/share/kservices5/kded/ and restart the session.
Comment 2 Ruman Gerst 2014-07-22 09:48:15 UTC
This is a very strange bug:

1. I take away half of the services
2. Relog
3. No CPU-eating (this would indicate that the evil module is is in that set)
4. I put them back
5. Relog
6. NO CPU-eating
7. Reboot
8. CPU eating, again
Comment 3 Ruman Gerst 2014-07-22 10:01:53 UTC
And even this is not 'reliable':

Rebooted, all services enabled, no kded5-CPU eating
Comment 4 NForce 2014-07-22 21:50:59 UTC
I can reproduce this most of the time. Here are the steps:
1. All the services are enabled
2. Use plasma normally then reboot/logout/kwin krash
3. Try to login - ksplash gets stuck at about 20%. After a while it disappears leaving a black screen with mouse only.
4. After a while plasmashell appears, but it's unusable, you can't start any application from it.
5. Check processes - kded5 is stuck, dbus-daemon is stuck too. Kill klipper process - it gets responsive for a short time

The only way to get around this for me - is to disable Keyboard Daemon from autostart, and start it manually, when kde is loaded
Comment 5 NForce 2014-07-22 21:53:31 UTC
Created attachment 87886 [details]
xsession-errors file

Managed to grab an xsession-errors log file when that happens - it looks like it tries to add systray icons in a loop until dbus gets flooded and stuck
Comment 6 kdeuser56 2014-08-14 10:07:45 UTC
I can confirm that problem, there seems to be a regression compared to kded4. I tried the latest kubuntu next cd and kded5 hogged the cpu the whole session long (100% on one core). For me the responsible module was the "Sim pin unlock required". The window appeared at the start of the session and was not closable, as it did not respond. kded5 kept on hogging the cpu until I killed it, problem was after a few seconds it started again and the sim dialog showed up again, same problem, not closable, 100% kded5 cpu.
Comment 7 Adrian Rocha 2014-08-15 06:09:49 UTC
I have the same problem. I'm testing the Kubuntu plasma 5 386 image of 14-Aug-2014 on a VM and since when the system starts this process uses 100% of CPU.
Comment 8 Alex Fiestas 2014-08-20 17:53:40 UTC
Hi, could you provide the following information ?

When kded5 is sucking CPU like a crazy, do:
1-ps aux | grep kded5  (grab the pid)
2-sudo gdb --pid ${pid of the process here}
3-thread apply all bt

Thanks!
Comment 9 Juho 2014-08-20 21:23:45 UTC
Hello Alex,

I found this bug report since I've got a similar issue - CPU usage of kded5 gets stuck at 25%. Here is the output of those commands:
http://pastey.org/view/2df71e67

I am running Arch Linux 3.16.1-1 with i3-330m and GeForce 310M (proprietary driver).
Comment 10 Adrian Rocha 2014-08-20 22:00:25 UTC
Created attachment 88339 [details]
gdb bt output

Hi,

Here the output in my case, kubuntu i386 14.10 (ISO of 19-Aug), the issue persists.

Best Regards
Comment 11 Hrvoje Senjan 2014-08-20 22:25:11 UTC
@Juho, Adrian,
your problem usually happens in case of invalid/non-existent/underprivileged DBus service.

Check do you have /usr/share/dbus-1/system-services/org.kde.powerdevil.backlighthelper.service file, with the correct executable inside. e.g. something like:

[D-BUS Service]
Name=org.kde.powerdevil.backlighthelper
Exec=/usr/lib64/libexec/kauth/backlighthelper
User=root
Comment 12 Juho 2014-08-20 22:47:32 UTC
Hey Hrvoje, this is what I found in there:

[D-BUS Service]
Name=org.kde.powerdevil.backlighthelper
Exec=/usr/lib/kde4/libexec/backlighthelper
User=root
Comment 13 Hrvoje Senjan 2014-08-20 23:13:46 UTC
i guess this is unsupported combination: as that is the helper from 4.x Plasma/PowerDevil
Comment 14 Juho 2014-08-20 23:25:17 UTC
I am not sure if powerdevil and kde version numbers go hand in hand, but it is powerdevil 5.0.1, installed as a dependency for plasma-desktop package in Arch User Repository.
Comment 15 Adrian Rocha 2014-08-20 23:34:02 UTC
Hi Hrvoje,

This file doesn't come in the kubuntu plasma 5 i386 image (utopic-desktop-i386.iso). At least at 19-Aug-2014...

Regards
Comment 16 AnAkkk 2014-08-23 17:39:21 UTC
I have exactly the same issue, except that it eats 50% of CPU for me. Backtrace is identical.

/usr/share/dbus-1/system-services/org.kde.powerdevil.backlighthelper.service:
[D-BUS Service]
Name=org.kde.powerdevil.backlighthelper
Exec=/usr/lib/kde4/libexec/backlighthelper
User=root

/opt/kf5/share/dbus-1/system-service/org.kde.powerdevil.backlighthelper.service:
[D-BUS Service]
Name=org.kde.powerdevil.backlighthelper
Exec=/opt/kf5/lib/libexec/kauth/backlighthelper
User=root


I guess it uses the one from /opt/kf5? the file pointed by that path exists.
Comment 17 Johan Manuel 2014-08-24 17:03:29 UTC
Removing powerdevil fixed it (pacman -Rdd powerdevil).
So is it a bug in powerdevil or plasmashell? Should powerdevil be removed from plasma-desktop's dependencies in AUR?
Thanks
Comment 18 AnAkkk 2014-08-24 17:08:38 UTC
Some people have the same issue in openSUSE. Apparently this might only happen when Powerdevil is installed in /opt/kf5. It would be nice if the AUR pkgbuilds would stop installing stuff in that place.
Comment 20 Hrvoje Senjan 2014-08-26 22:07:45 UTC
(In reply to AnAkkk from comment #16)
> I guess it uses the one from /opt/kf5? the file pointed by that path exists.


there is no rule unfortunately with DBus activation per-name: if there are multiple services with same name, it cannot be known which one will be activated.
only way to be sure is to have:
/usr/share/dbus-1/system-service/org.kde.powerdevil.backlighthelper.service:
[D-BUS Service]
Name=org.kde.powerdevil.backlighthelper
Exec=$libexec_path/kauth/backlighthelper
User=root

if it's missing on your system, it's a packaging bug.
if you have 4.x version, it won't work with Plasma5 PowerDevil...
Comment 21 kdeuser56 2014-08-27 17:54:48 UTC
Created attachment 88458 [details]
GDB output as requested

Sorry for the late respone, here is my gdb output.
Comment 22 kdeuser56 2014-08-28 09:54:16 UTC
To be more precise and demonstrate the circumstances I experience this bug see the following screencast:
https://drive.google.com/file/d/0B-ihXi2hkCPfVndCbVZTeUpLb0k/edit?usp=sharing

The konsole output of kded5 when starting in the screencast can be found here:
https://drive.google.com/file/d/0B-ihXi2hkCPfZXdWSWVONXMwU0E/edit?usp=sharing

The gdb trace taken during the screencast can be found here:
https://drive.google.com/file/d/0B-ihXi2hkCPfVUw5MnB3NGZBNkE/edit?usp=sharing
Comment 23 Scarlett Moore 2014-08-28 19:05:41 UTC
For the Kubuntu users missing
/usr/share/dbus-1/system-services/org.kde.powerdevil.backlighthelper.service

altogether, this has been resolved and uploaded to the next PPA.
Comment 24 Adrian Rocha 2014-08-31 05:18:10 UTC
In Kubuntu Plasma 5 i386 the problem is solved. Now I can see the file /usr/share/dbus-1/system-services/org.kde.powerdevil.backlighthelper.service
Apparently it was a packaging issue, at least in my case.
Comment 25 Martin Klapetek 2014-09-25 22:53:47 UTC
As the Kubuntu case was a packaging issue and as Hrvoje is suggesting the same for openSuse, I'm closing this as a downstream issue.

Thanks for the reports everyone
Comment 26 Antonis G. 2015-01-11 18:44:18 UTC
Hello kded5 consumes 25% cpu here. There are to kded5 process one owned by sddm:
ps aux | grep kded5 
sddm      1558  0.0  0.5 372604 21892 ?        Sl   16:58   0:01 /usr/bin/kded5
jourgen  15432 21.0  1.4 1595880 56728 ?       Rl   20:20   2:03 /usr/bin/kded5 

I kill the one owned by my user but when I reloggin to my machine it gets spawned again and consumes 25% cpu.

Archlinux kf5.6 packages and plasmashell built from git as of today
Here is the bt: https://paste.kde.org/p3q7ztuyq
Comment 27 Martin Klapetek 2015-01-11 18:51:24 UTC
Hmm, could you possibly install powerdevil's debug packages and try again? Would be cool to also throw qt debug packages there too...
Comment 28 Antonis G. 2015-01-12 21:55:34 UTC
Here https://paste.kde.org/pbi7czm99
Comment 29 Martin Klapetek 2015-01-12 22:08:26 UTC
I'm not sure if I'm reading this correctly but it looks like

PowerDevilUPowerBackend::brightnessValue execs a job and inside this new event loop the
PowerDevilUPowerBackend::brightnessValueMax execs a job and then inside PowerDevilUPowerBackend::brightnessValue execs a job and then PowerDevilUPowerBackend::brightnessValueMax execs a new job...?
Comment 30 Hrvoje Senjan 2015-01-13 02:09:34 UTC
Created attachment 90381 [details]
sligthly more debug

i am also getting the CPU murdering after recent changes to powerdevil dataengine & powerdevil itself (see also bug 342597)

this one can be reproduced on my setup at 99% of the time after doing a switch user routine. after going back to original session, kded5 is busy
Comment 31 Martin Klapetek 2015-01-15 12:51:16 UTC
*** Bug 341775 has been marked as a duplicate of this bug. ***
Comment 32 Marco Martin 2015-01-15 12:59:25 UTC
more than kded5 eating 100% cpu is perhaps it dying and restarting all the time? (i get that sometimes)
Comment 33 Hrvoje Senjan 2015-01-15 13:10:52 UTC
nope, it is the same process
Comment 34 Mykola Krachkovsky 2015-01-16 13:22:10 UTC
Same for me. kded5 consumes 1 core. I'm using notebook, if I change monitor brightness cpu usage is lowered to 0%, but after time may up again.
Comment 35 Tajidin Abd 2015-01-16 19:09:34 UTC
Also on Archlinux git build the kded5 is killing one core on my machine at 100%. If i kill it things return to normal
Comment 36 Steven Franzen 2015-01-16 22:53:28 UTC
(In reply to Mykola Krachkovsky from comment #34)
> Same for me. kded5 consumes 1 core. I'm using notebook, if I change monitor
> brightness cpu usage is lowered to 0%, but after time may up again.

This trick also works for me.

I can further report that I can reliably trigger the CPU usage manually by unlocking (not just locking) the screen from the screen locker.
Comment 37 David Edmundson 2015-01-18 14:23:29 UTC
Can you guys confirm what distro and where you get your Plasma 5 from. Is it self-installed? It seems like a polkit problem.

Also can you show me the output of:
pkaction -a org.kde.powerdevil.backlighthelper.syspath
Comment 38 Luca Beltrame 2015-01-18 14:46:30 UTC
In data domenica 18 gennaio 2015 14:23:29, hai scritto:

> Can you guys confirm what distro and where you get your Plasma 5 from. Is it
> self-installed? It seems like a polkit problem.

In my and Hrvoje's cases is from openSUSE, using distro-supplied packagign.

> pkaction -a org.kde.powerdevil.backlighthelper.syspath

All I get is:

[lb@leon ~]$ pkaction -a org.kde.powerdevil.backlighthelper.syspath
org.kde.powerdevil.backlighthelper.syspath
Comment 39 David Edmundson 2015-01-18 14:47:53 UTC
ok, that's fine. That's what you're meant to see.
Comment 40 Antonis G. 2015-01-18 19:11:09 UTC
I got sddm, polkit and framework packages from archlinux, all the rest from git. Is it normal to have two kded5 processes running: ps -aux | grep kded5
sddm       460  0.0  0.5 372612 21968 ?        Sl   20:50   0:00 /usr/bin/kded5
jourgen    542  0.0  1.5 1704232 59392 ?       Sl   20:50   0:00 kded5 [kdeinit5]
Comment 41 David Edmundson 2015-01-18 19:12:51 UTC
> Is it normal to have two kded5 processes running: ps -aux | grep kded5

No. SDDM should be killing whatever it launches from the greeter
Comment 42 Hrvoje Senjan 2015-01-18 19:23:54 UTC
i'm also having two kded5 processes, user's and sddm's. however, only users goes wild.
Comment 43 Martin Klapetek 2015-01-18 20:40:09 UTC
Fwiw (with regards to those sddm comments) I use lightdm and have never seen this issue.
Comment 44 Hrvoje Senjan 2015-01-18 20:50:42 UTC
i've just tried kdm, and managed to reproduce the issue still...

it's essential that the helper, and not XRandBrightness is used.
also, i've tried locally to revert the logic in powerdevil (switch to !job->exec(), instead of checking it's successful first, and that resolved for me bug 342597. one caveat is that the slider then has 9/9 which is a regression i'd say compared to 5.1.x. the logic switch does not help this bug though)
Comment 45 Steven Franzen 2015-01-18 21:28:02 UTC
(In reply to David Edmundson from comment #37)
> Can you guys confirm what distro and where you get your Plasma 5 from.
I have Fedora 21 with Plasma 5.1.95 and KF 5.6 installed from Daniel Vrátil's custom repositories.

> Also can you show me the output of:
> pkaction -a org.kde.powerdevil.backlighthelper.syspath
org.kde.powerdevil.backlighthelper.syspath

Re: SDDM:
I also use SDDM (version 0.10.0), but I only have a single instance of kded5 running.
Comment 46 Kai Uwe Broulik 2015-01-18 22:24:26 UTC
Git commit 62fbfd5b15234ff38aa11ed131474991a193d17b by Kai Uwe Broulik.
Committed on 18/01/2015 at 22:19.
Pushed by broulik into branch 'Plasma/5.2'.

Remove explicit source request

This was there to initially populate the dataengine. But since the requests are all
asynchronous the data won't be there on time anyway, so let's just wait until somebody
explicitly requests the source which was done by batterymonitor anyway resulting in two
subsequent calls potentially confusing PowerDevil and causing it to go nuts.

M  +0    -2    dataengines/powermanagement/powermanagementengine.cpp

http://commits.kde.org/plasma-workspace/62fbfd5b15234ff38aa11ed131474991a193d17b
Comment 47 Kai Uwe Broulik 2015-01-20 08:10:56 UTC
Apparently this fixed the issue. Feel free to re-open if the issue persists.
Comment 48 Tajidin Abd 2015-01-20 16:16:19 UTC
well for me it seems that when i login to Plasma5 kded5 is crashing from the start. I wish i could provide you a backtrace. It is saying Segmentation fault

I am using the lastest build from git. I use the AUR repo from Archlinux. 
The lastest commit seems to crash kded5
Comment 49 Antonis G. 2015-01-23 13:00:42 UTC
Still happening, nothing changed. I should also add that Battery plasmoid reports "No screen or keyboard brightness controls available.
Comment 50 Nick Shaforostoff 2015-01-28 23:05:03 UTC
i don't know whether the fix is installed in my vivid (most packages have 5.1.95 version), but i'm able to reproduce high cpu usage by connecting external monitor.

when i connect external monitor, it has black background and immediately everything becomes slow: at first 'top' shows that 4 'migration' processes are taking cpu time, then after a while kded5 eats 100% cpu time (it goes crazy with PowerDevilUPowerBackend::brightnessValueMax() and PowerDevilUPowerBackend::brightnessValue()).
Comment 51 Ruman Gerst 2015-01-28 23:53:10 UTC
Huh? What happened?

It was gone for me with Plasma 5.1.1, now I'm using Plasma 5.2 from Kubuntu Next Backports - now it's back!

I'll post a sysprof file, again.
Comment 52 Ruman Gerst 2015-01-28 23:54:24 UTC
Created attachment 90766 [details]
Output from sudo sysprof now with Plasma 5.2 [Kubuntu Next Backports]
Comment 53 Nick Shaforostoff 2015-01-29 00:16:29 UTC
i have updated packages to 5.2 version and the issue is still there.

i can see it after screenlocker run as well.
Comment 54 Dick Tracey 2015-01-29 02:18:35 UTC
Running 5.2, all the same here.
Comment 55 Kai Uwe Broulik 2015-01-29 10:17:57 UTC
Does anyone of you have the possibility of reproducing this with an up to date KAuth, specifically this [1] patch? There have been attempts to fix the KJob fallback getting stuck but this patch will only be in Frameworks 5.7 which is not yet released.

[1] https://git.reviewboard.kde.org/r/122029/
Comment 56 Nick Shaforostoff 2015-01-29 11:00:13 UTC
are you this patch would really matter, taking into account the fact that i have  /usr/share/dbus-1/system-services/org.kde.powerdevil.backlighthelper.service  pointing to existing executable, which is linked against kf5 libraries?
Comment 57 David Edmundson 2015-01-29 15:26:04 UTC
Can someone try this please 
https://git.reviewboard.kde.org/r/122307/
Comment 58 Hrvoje Senjan 2015-01-29 16:31:05 UTC
from short testing the patch seems to resolves the CPU problem.
however:
1) for locking the screen, it now takes some 30s to actually show the locker,
2) konsole action (right click) is blocked with:

0  0x00007f6f482e94ad in poll () at /lib64/libc.so.6
#1  0x00007f6f3bf1926a in  () at /lib64/libdbus-1.so.3
#2  0x00007f6f3bf180bf in  () at /lib64/libdbus-1.so.3
#3  0x00007f6f3bf025bc in  () at /lib64/libdbus-1.so.3
#4  0x00007f6f3bf02f69 in  () at /lib64/libdbus-1.so.3
#5  0x00007f6f3bf0352d in dbus_connection_send_with_reply_and_block ()
    at /lib64/libdbus-1.so.3
#6  0x00007f6f42666780 in QDBusConnectionPrivate::sendWithReply(QDBusMessage const&, int, int) (error=0x7fff89162670, timeout_milliseconds=-1, message=0x2077aa0, connection=<optimized out>) at qdbus_symbols_p.h:135
#7  0x00007f6f42666780 in QDBusConnectionPrivate::sendWithReply(QDBusMessage const&, int, int) (this=
    0x206b910, message=..., sendMode=<optimized out>, timeout=-1)
    at qdbusintegrator.cpp:2046
#8  0x00007f6f426533c3 in QDBusConnection::call(QDBusMessage const&, QDBus::CallMode, int) const (this=this@entry=0x23e2b10, message=..., mode=mode@entry=QDBus::Block, timeout=<optimized out>) at qdbusconnection.cpp:576
#9  0x00007f6f426717ef in QDBusAbstractInterface::callWithArgumentList(QDBus::CallMode, QString const&, QList<QVariant> const&) (this=this@entry=0x7fff891629b0, mode=QDBus::Block, mode@entry=QDBus::AutoDetect, method=..., args=...)
    at qdbusabstractinterface.cpp:476
#10 0x00007f6f426725b5 in QDBusAbstractInterface::call(QDBus::CallMode, QString const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVar---Type <return> to continue, or q <return> to quit---
iant const&, QVariant const&, QVariant const&, QVariant const&) (this=this@entry=0x7fff891629b0, mode=mode@entry=QDBus::AutoDetect, method=..., arg1=..., arg2=..., arg3=..., arg4=..., arg5=..., arg6=..., arg7=..., arg8=...)
    at qdbusabstractinterface.cpp:746
#11 0x00007f6f42672771 in QDBusAbstractInterface::call(QString const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&) (this=this@entry=0x7fff891629b0, method=..., arg1=..., arg2=..., arg3=..., arg4=..., arg5=..., arg6=..., arg7=..., arg8=...) at qdbusabstractinterface.cpp:689
#12 0x00007f6f433c783c in KIO::favIconForUrl(QUrl const&) (url=...)
    at /usr/src/debug/kio-5.7.0git/src/core/global.cpp:339
#13 0x00007f6f433c8085 in KIO::iconNameForUrl(QUrl const&) (url=...)
    at /usr/src/debug/kio-5.7.0git/src/core/global.cpp:356
#14 0x00007f6f21034352 in SearchProvider::iconName() const (this=<optimized out>) at /usr/src/debug/kio-5.7.0git/src/urifilters/ikws/searchprovider.cpp:111
#15 0x00007f6f4731313a in KUriFilterData::iconNameForPreferredSearchProvider(QString const&) const (this=<optimized out>, provider=...)
    at /usr/src/debug/kio-5.7.0git/src/widgets/kurifilter.cpp:381
#16 0x00007f6f47f83883 in Konsole::SessionController::updateWebSearchMenu() ()
    at /usr/lib64/libkonsoleprivate.so.3
#17 0x00007f6f47f89697 in Konsole::SessionController::showDisplayContextMenu(QPoint const&) () at /usr/lib64/libkonsoleprivate.so.3
#18 0x00007f6f4494e12f in QMetaObject::activate(QObject*, int, int, void**) (a=0---Type <return> to continue, or q <return> to quit---
x7fff89162eb0, r=0x2384940, this=0x2380270)
    at ../../src/corelib/kernel/qobject_impl.h:124
#19 0x00007f6f4494e12f in QMetaObject::activate(QObject*, int, int, void**) (sender=0x23efd50, signalOffset=<optimized out>, local_signal_index=<optimized out>, argv=0x7fff89162eb0) at kernel/qobject.cpp:3702
#20 0x00007f6f47fbfc55 in Konsole::TerminalDisplay::configureRequest(QPoint const&) () at /usr/lib64/libkonsoleprivate.so.3
#21 0x00007f6f47fa5269 in Konsole::TerminalDisplay::mousePressEvent(QMouseEvent*) () at /usr/lib64/libkonsoleprivate.so.3
#22 0x00007f6f4561d50a in QWidget::event(QEvent*) (this=0x23efd50, event=
    0x7fff891633b0) at kernel/qwidget.cpp:8652
#23 0x00007f6f47fa5cca in Konsole::TerminalDisplay::event(QEvent*) ()
    at /usr/lib64/libkonsoleprivate.so.3
#24 0x00007f6f455ddb5c in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=this@entry=0x2094b20, receiver=receiver@entry=0x23efd50, e=e@entry=0x7fff891633b0) at kernel/qapplication.cpp:3722
#25 0x00007f6f455e34e6 in QApplication::notify(QObject*, QEvent*) (this=<optimized out>, receiver=0x23efd50, e=0x7fff891633b0) at kernel/qapplication.cpp:3280
#26 0x00007f6f4491ee55 in QCoreApplication::notifyInternal(QObject*, QEvent*) (this=
    0x7fff89163cd0, receiver=receiver@entry=0x23efd50, event=event@entry=0x7fff891633b0) at kernel/qcoreapplication.cpp:930
#27 0x00007f6f455e1eb1 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEv---Type <return> to continue, or q <return> to quit---
ent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) (event=0x7fff891633b0, receiver=0x23efd50) at ../../src/corelib/kernel/qcoreapplication.h:231
#28 0x00007f6f455e1eb1 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) (receiver=receiver@entry=0x23efd50, event=event@entry=
    0x7fff891633b0, alienWidget=alienWidget@entry=0x23efd50, nativeWidget=0x216ff90, buttonDown=buttonDown@entry=0x7f6f45cef5f0 <qt_button_down>, lastMouseReceiver=..., spontaneous=spontaneous@entry=true) at kernel/qapplication.cpp:2751
#29 0x00007f6f45634c56 in QWidgetWindow::handleMouseEvent(QMouseEvent*) (this=this@entry=0x21db900, event=event@entry=0x7fff89163800)
    at kernel/qwidgetwindow.cpp:543
#30 0x00007f6f45636b6b in QWidgetWindow::event(QEvent*) (this=0x21db900, event=0x7fff89163800) at kernel/qwidgetwindow.cpp:210
#31 0x00007f6f455ddb5c in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=this@entry=0x2094b20, receiver=receiver@entry=0x21db900, e=e@entry=0x7fff89163800) at kernel/qapplication.cpp:3722
#32 0x00007f6f455e2bc0 in QApplication::notify(QObject*, QEvent*) (this=0x7fff89163cd0, receiver=0x21db900, e=0x7fff89163800) at kernel/qapplication.cpp:3505
#33 0x00007f6f4491ee55 in QCoreApplication::notifyInternal(QObject*, QEvent*) (this=0x7fff89163cd0, receiver=receiver@entry=0x21db900, event=event@entry=0x7fff89163800) at kernel/qcoreapplication.cpp:930
#34 0x00007f6f44e548ee in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) (event=0x7fff89163800, receiver=0x21db900)
    at ../../src/corelib/kernel/qcoreapplication.h:231
#35 0x00007f6f44e548ee in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) (e=0x23cfe30)
    at kernel/qguiapplication.cpp:1771
#36 0x00007f6f44e56105 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) (e=e@entry=0x23cfe30)
    at kernel/qguiapplication.cpp:1573
#37 0x00007f6f44e3c9b8 in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) (flags=...)
    at kernel/qwindowsysteminterface.cpp:572
#38 0x00007f6f354722f0 in userEventSourceDispatch(GSource*, GSourceFunc, gpointer) (source=<optimized out>) at eventdispatchers/qeventdispatcher_glib.cpp:70
#39 0x00007f6f3ee3fa04 in g_main_context_dispatch ()
    at /usr/lib64/libglib-2.0.so.0
#40 0x00007f6f3ee3fc48 in  () at /usr/lib64/libglib-2.0.so.0
#41 0x00007f6f3ee3fcec in g_main_context_iteration ()
    at /usr/lib64/libglib-2.0.so.0
#42 0x00007f6f4497619c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x20d98d0, flags=...)
    at kernel/qeventdispatcher_glib.cpp:418
#43 0x00007f6f4491cdab in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7fff89163b80, flags=..., flags@entry=...)
    at kernel/qeventloop.cpp:204
#44 0x00007f6f44924436 in QCoreApplication::exec() ()
    at kernel/qcoreapplication.cpp:1183
#45 0x00007f6f485cc37d in kdemain () at /usr/lib64/libkdeinit5_konsole.so
#46 0x00007f6f4822eb45 in __libc_start_main () at /lib64/libc.so.6
#47 0x00000000004007ee in _start ()
Comment 59 Nick Shaforostoff 2015-01-29 16:34:41 UTC
yeah, generally kde5 became slower on my netbook. it takes 5 seconds for alt+f2 runner to start reacting to my input, it takes ~5 seconds for start menu and simple alt+tab switcher to appear, and it takes ~5-10 seconds just to show session-end/reboot/poweroff confirmation screen.
Comment 60 Hrvoje Senjan 2015-01-29 16:48:28 UTC
kded5 bt w/ Davids patch:

#0  0x00007f505a91685f in pthread_cond_wait@@GLIBC_2.3.2 ()
    at /lib64/libpthread.so.0
#1  0x00007f505b89796b in QWaitCondition::wait(QMutex*, unsigned long) (time=18446744073709551615, this=0xd11fe0) at thread/qwaitcondition_unix.cpp:128
#2  0x00007f505b89796b in QWaitCondition::wait(QMutex*, unsigned long) (this=this@entry=0xd11fc8, mutex=mutex@entry=0xd11fa0, time=time@entry=18446744073709551615) at thread/qwaitcondition_unix.cpp:200
#3  0x00007f505b89657e in QThread::wait(unsigned long) (this=this@entry=
    0x7fffac915880, time=time@entry=18446744073709551615)
    at thread/qthread_unix.cpp:670
#4  0x00007f502ad73462 in PowerDevilUPowerBackend::kjobExecInThread(KJob*) (job=job@entry=0xd95ed0)
    at /home/hrvoje/Src/local/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp:594
#5  0x00007f502ad73576 in PowerDevilUPowerBackend::brightnessValue(PowerDevil::BackendInterface::BrightnessControlType) const (this=
    0xb6d580, type=<optimized out>)
    at /home/hrvoje/Src/local/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp:308
#6  0x00007f502ad710cd in PowerDevilUPowerBackend::init() (this=<optimized out>) at /home/hrvoje/Src/local/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp:182
#7  0x00007f502ab215db in PowerDevil::Core::loadCore(PowerDevil::BackendInterfac---Type <return> to continue, or q <return> to quit---
e*) (this=0xcb51a0, backend=backend@entry=0xb6d580)
    at /home/hrvoje/Src/local/powerdevil/daemon/powerdevilcore.cpp:87
#8  0x00007f502ad649bc in KDEDPowerDevil::init() (this=0xc87670)
    at /home/hrvoje/Src/local/powerdevil/daemon/kdedpowerdevil.cpp:89
#9  0x00007f505baa1506 in QObject::event(QEvent*) (this=0xc87670, e=<optimized out>) at kernel/qobject.cpp:1245
#10 0x00007f505c72fb5c in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=this@entry=0x8a9bf0, receiver=receiver@entry=0xc87670, e=e@entry=
    0xc74760) at kernel/qapplication.cpp:3722
#11 0x00007f505c734bc0 in QApplication::notify(QObject*, QEvent*) (this=
    0x7fffac916350, receiver=0xc87670, e=0xc74760)
    at kernel/qapplication.cpp:3505
#12 0x00007f505ba70e55 in QCoreApplication::notifyInternal(QObject*, QEvent*) (this=0x7fffac916350, receiver=0xc87670, event=event@entry=0xc74760)
    at kernel/qcoreapplication.cpp:930
#13 0x00007f505ba72cef in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (event=0xc74760, receiver=<optimized out>)
    at kernel/qcoreapplication.h:228
#14 0x00007f505ba72cef in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x8a9d60) at kernel/qcoreapplication.cpp:1534
#15 0x00007f505ba73328 in QCoreApplication::sendPostedEvents(QObject*, int) (receiver=receiver@entry=0x0, event_type=event_type@entry=0)
---Type <return> to continue, or q <return> to quit---
    at kernel/qcoreapplication.cpp:1392
#16 0x00007f505bac8d23 in postEventSourceDispatch(GSource*, GSourceFunc, gpointer) (s=0x91bed0) at kernel/qeventdispatcher_glib.cpp:271
#17 0x00007f5059c97a04 in g_main_context_dispatch ()
    at /usr/lib64/libglib-2.0.so.0
#18 0x00007f5059c97c48 in  () at /usr/lib64/libglib-2.0.so.0
#19 0x00007f5059c97cec in g_main_context_iteration ()
    at /usr/lib64/libglib-2.0.so.0
#20 0x00007f505bac819c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x9105c0, flags=...)
    at kernel/qeventdispatcher_glib.cpp:418
#21 0x00007f505ba6edab in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7fffac916280, flags=..., flags@entry=...)
    at kernel/qeventloop.cpp:204
#22 0x00007f505ba76436 in QCoreApplication::exec() ()
    at kernel/qcoreapplication.cpp:1183
#23 0x00007f505dfcf73a in kdemain () at /usr/lib64/libkdeinit5_kded5.so
#24 0x00007f505dc48b45 in __libc_start_main () at /lib64/libc.so.6
#25 0x00000000004007ee in _start ()
Comment 61 David Edmundson 2015-01-29 17:02:42 UTC
Thanks for testing.

It seems the only solution will be to remove these blocking KAuth calls throughout this function. It's a wrong thing to be doing from kded.

I suggest we query brightnessValueMax in init();
and use m_cachedBrightnessMap for both the getters.

For the set case, we don't really need to wait for a reply. Is the error code really that useful?
Comment 62 Kai Uwe Broulik 2015-01-29 21:48:53 UTC
Git commit 2c2c13751e19b0a37bb8b41096b08f80383e61df by Kai Uwe Broulik.
Committed on 29/01/2015 at 21:46.
Pushed by broulik into branch 'Plasma/5.2'.

Fix PowerDevil brightness calls breaking kded, Volume 3521

Query both brightness and maximum only once and then only listen to udev change
events and just kick off the set job and forget about it. That way we do not have
nested event loops outside the init method anymore.
FIXED-IN: 5.2.1

This prevents re-entrancy issues

M  +23   -6    daemon/actions/bundled/brightnesscontrol.cpp
M  +2    -0    daemon/actions/bundled/brightnesscontrol.h
M  +5    -3    daemon/backends/hal/powerdevilhalbackend.cpp
M  +1    -1    daemon/backends/hal/powerdevilhalbackend.h
M  +41   -42   daemon/backends/upower/powerdevilupowerbackend.cpp
M  +2    -1    daemon/backends/upower/powerdevilupowerbackend.h
M  +2    -1    daemon/powerdevilbackendinterface.h

http://commits.kde.org/powerdevil/2c2c13751e19b0a37bb8b41096b08f80383e61df
Comment 63 David Edmundson 2015-01-29 22:02:42 UTC
*** Bug 343542 has been marked as a duplicate of this bug. ***
Comment 64 Jürgen Scholz 2015-01-30 12:50:22 UTC
Created attachment 90813 [details]
gdb trace of kded5 5.6.0-0ubuntu1

I run into the "kded5 is using 100% of one CPU core" issue every ~30 minutes. It is 100% reproducible by just letting my PC sit while I am logged in without any programs running.

I did the gdb trace even when I have no idea how to interpet the output. The machine I am on is a not-dist-upgraded (read: fresh) installation of kubuntu vivid. The KDE version is 5.2 since ubuntu updated it's packages a few days ago.

I am using the home directory of my old kubuntu installation. However this also happens with a newly created user with a new home directory.

Can I help with additional information/tests to diagnose the issue?

Thank you for reading. Cheers!
Comment 65 Christoph Feck 2015-01-30 14:45:55 UTC
> Can I help with additional information/tests to diagnose the issue?

Yes, test Plasma 5.2.1, since this will contain the commit from yesterday (see comment #62).
Comment 66 Nick Shaforostoff 2015-01-30 23:48:12 UTC
i have compiled powerdevil and placed two .so libraries that were present in bactraces into the system, rebooted and now issue is gone.

both on external monitor connect and screenlocker launch.
Comment 67 Thayne 2015-02-02 05:10:06 UTC
I get kded5 using 100% of one core fairly often. I've tried disabling the power management service. I'll see if that works as a temporary fix.
Comment 68 Jürgen Scholz 2015-02-16 16:11:14 UTC
I updated to new versions of kded5 and plasma-desktop/plasma-framework a few days ago. The versions are now:
  kded (5.7.0-0ubuntu1) vivid; urgency=medium
  plasma-desktop (4:5.2.0-0ubuntu1) vivid; urgency=medium
  plasma-framework (5.7.0-0ubuntu1) vivid; urgency=medium

Turning off power saving of the monitors seems to be an effective work-around.

If I turn energy management back on, kded5 is starting to use one cpu core again.

I will attach another gdb stack trace.
Comment 69 Jürgen Scholz 2015-02-16 16:13:43 UTC
Oh, please excuse my oversidght. ubuntu still uses 5.2.0 and *not* 5.2.1. I will check their bugtracker to either fix this as a backport or to switch to 5.2.1.
Comment 70 Christoph Feck 2015-02-16 16:17:08 UTC
This bug was fixed for 5.2.1, so there is no need to attach log files from 5.2.0.
Comment 71 Jürgen Scholz 2015-03-09 23:30:20 UTC
I am kind of late to the party. Ubuntu updated it's packages a while ago and everything is running smoothly now.

Thank you very much for all your work! :)
Comment 72 miflab 2015-12-06 09:59:29 UTC
I have same issue (25% CPU usage of kded5) on my plasma 5.4.3.
kde-frameworks/kded 5.16.0
kde-plasma/plasma-desktop 5.4.3
kde-plasma/powerdevil 5.4.3
Comment 73 Martin Klapetek 2015-12-07 17:17:40 UTC
Please follow the steps from Comment #8.
Comment 74 miflab 2015-12-11 06:49:57 UTC
bt here - http://pastebin.com/dxUkvRMx
kde-frameworks/kded 5.16.0
kde-plasma/plasma-desktop 5.5.0
kde-plasma/powerdevil 5.5.0
Comment 75 Martin Klapetek 2015-12-11 19:00:55 UTC
Thanks, pasting it here. Always please either attach the file here or paste it directly here, pastebins tend to disappear. That said, your backtrace looks absolutely normal, there's nothing wrong going on (in fact there is /nothing/ going on). Are you sure this is when the kded5 process is eating the cpu?

---

(gdb) thread apply all bt

Thread 5 (Thread 0x7ff9a51c5700 (LWP 22153)):
#0  0x00007ff9b537832d in poll () from /lib64/libc.so.6
#1  0x00007ff9b4ae3ac2 in ?? () from /usr/lib64/libxcb.so.1
#2  0x00007ff9b4ae572f in xcb_wait_for_event () from /usr/lib64/libxcb.so.1
#3  0x00007ff9a6cfdcb9 in ?? () from /usr/lib64/libQt5XcbQpa.so.5
#4  0x00007ff9b56d4082 in ?? () from /usr/lib64/libQt5Core.so.5
#5  0x00007ff9b31f2444 in start_thread () from /lib64/libpthread.so.0
#6  0x00007ff9b538130d in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7ff993318700 (LWP 22220)):
#0  0x00007ff9b537832d in poll () from /lib64/libc.so.6
#1  0x00007ff9b249deec in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007ff9b249dffc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007ff9b58cb847 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib64/libQt5Core.so.5
#4  0x00007ff9b587d41a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#5  0x00007ff9b56cf6d4 in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#6  0x00007ff9b56d4082 in ?? () from /usr/lib64/libQt5Core.so.5
#7  0x00007ff9b31f2444 in start_thread () from /lib64/libpthread.so.0
#8  0x00007ff9b538130d in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7ff9835e7700 (LWP 29419)):
#0  0x00007ff9b31f83b8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007ff983dbb8eb in vlc_cond_timedwait () from /usr/lib64/libvlccore.so.8
---Type <return> to continue, or q <return> to quit---
#2  0x00007ff983d7e07c in ?? () from /usr/lib64/libvlccore.so.8
#3  0x00007ff983d7eb55 in ?? () from /usr/lib64/libvlccore.so.8
#4  0x00007ff9b31f2444 in start_thread () from /lib64/libpthread.so.0
#5  0x00007ff9b538130d in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7ff980137700 (LWP 29421)):
#0  0x00007ff9b5382b27 in semop () from /lib64/libc.so.6
#1  0x00007ff98366afd7 in ?? () from /usr/lib64/libasound.so.2
#2  0x00007ff983639196 in snd_pcm_recover () from /usr/lib64/libasound.so.2
#3  0x00007ff9900261bf in ?? () from /usr/lib64/vlc/plugins/audio_output/libalsa_plugin.so
#4  0x00007ff983d98f83 in ?? () from /usr/lib64/libvlccore.so.8
#5  0x00007ff983d6cc12 in ?? () from /usr/lib64/libvlccore.so.8
#6  0x00007ff983d6e06b in ?? () from /usr/lib64/libvlccore.so.8
#7  0x00007ff9b31f2444 in start_thread () from /lib64/libpthread.so.0
#8  0x00007ff9b538130d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7ff9b6a8e800 (LWP 22151)):
#0  0x00007ff9b537832d in poll () from /lib64/libc.so.6
#1  0x00007ff9b249deec in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007ff9b249dffc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007ff9b58cb847 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib64/libQt5Core.so.5
#4  0x00007ff9b587d41a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#5  0x00007ff9b58846fc in QCoreApplication::exec() () from /usr/lib64/libQt5Core.so.5
#6  0x00007ff9a6db5c88 in kdemain () from /usr/lib64/libkdeinit5_kded5.so
---Type <return> to continue, or q <return> to quit---
#7  0x0000000000408560 in ?? ()
#8  0x000000000040594d in main ()
(gdb)
Comment 76 miflab 2015-12-16 07:32:49 UTC
Created attachment 96116 [details]
kded5 cpu usage
Comment 77 miflab 2015-12-16 07:34:15 UTC
Created attachment 96117 [details]
thread apply all bt
Comment 78 miflab 2015-12-16 07:35:19 UTC
(In reply to Martin Klapetek from comment #75)
> Are you sure this is when the kded5 process is eating the cpu?
Yep today I got this again. I attached screenshoot and new bt.
Comment 79 Martin Klapetek 2015-12-16 16:27:21 UTC
Can you check if you have 2 kded5 processes running?
Your backtrace again shows no activity at all.
Comment 80 miflab 2015-12-16 18:45:57 UTC
(In reply to Martin Klapetek from comment #79)
> Can you check if you have 2 kded5 processes running?
Not sure, this issue is very random, but i'll try.
Also I notice that after do `sudo gdb --pid` cpu usage slightly decrease and after quit this back to 25%.
Comment 81 Martin Klapetek 2015-12-16 18:50:09 UTC
> Also I notice that after do `sudo gdb --pid` cpu usage slightly decrease and after quit this back to 25%.

Yes, attaching gdb to it makes the process actually stop,
quitting gdb makes the process continue.
Comment 82 miflab 2015-12-29 16:58:56 UTC
Created attachment 96361 [details]
bt

And another bt...
Comment 83 Martin Klapetek 2015-12-29 19:35:08 UTC
Can you check if you have 2 kded5 processes running?
Your backtrace again shows no activity at all.

That said, please compare the backtrace with the previous ones
before you upload a new one, there's no point uploading the same
backtrace again and again.

Lastly, the only thing of interest in the backtrace is libvlc+alsa,
hard to tell where is this coming from though.
Comment 84 miflab 2016-01-09 22:50:27 UTC
Created attachment 96551 [details]
screenshot

Well, now it eats ~40% with same bt. And here still only one kded5 process.
I no have any ideas what's going on...
Comment 85 Francesco 2016-01-22 18:52:33 UTC
(In reply to miflab from comment #84)

> Well, now it eats ~40% with same bt. And here still only one kded5 process.
> I no have any ideas what's going on...

Same here, same bt. Powerdevil 5.5.3 on gentoo amd64.
Comment 86 miflab 2016-01-23 15:06:32 UTC
(In reply to Francesco from comment #85)
> Same here, same bt. Powerdevil 5.5.3 on gentoo amd64.
Oh, yep, I use Gentoo too, ~amd64 profile.
Comment 87 Trioxin 2016-03-26 22:33:32 UTC
Not verified fixed for me. kded5 is killing my CPU at a constant 25%.

Kubuntu 15.10
Plasma: 5.4.2
QT: 5.4.2

Debug info: http://hastebin.com/uqoriyuhoq.avrasm
Comment 88 Christoph Feck 2016-03-27 02:27:38 UTC
Please check which kded module is responsible. You can disable them in the SystemSettings Service Manager.