Bug 337674

Could you check which kded module is responsible? You can move individual modules away from /usr/share/kservices5/kded/ and restart the session.

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

And even this is not 'reliable':

Rebooted, all services enabled, no kded5-CPU eating

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

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

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.

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.

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!

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).

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

@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

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

i guess this is unsupported combination: as that is the helper from 4.x Plasma/PowerDevil

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.

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

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.

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

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.

Forgot the link:
http://forums.opensuse.org/showthread.php/499607-KDE5?p=2654741#post2654741

(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...

Created attachment 88458 [details]
GDB output as requested

Sorry for the late respone, here is my gdb output.

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

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.

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.

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

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

Hmm, could you possibly install powerdevil's debug packages and try again? Would be cool to also throw qt debug packages there too...

Here https://paste.kde.org/pbi7czm99

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...?

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

*** Bug 341775 has been marked as a duplicate of this bug. ***

more than kded5 eating 100% cpu is perhaps it dying and restarting all the time? (i get that sometimes)

nope, it is the same process

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.

Also on Archlinux git build the kded5 is killing one core on my machine at 100%. If i kill it things return to normal

(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.

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

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

ok, that's fine. That's what you're meant to see.

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]

> Is it normal to have two kded5 processes running: ps -aux | grep kded5

No. SDDM should be killing whatever it launches from the greeter

i'm also having two kded5 processes, user's and sddm's. however, only users goes wild.

Fwiw (with regards to those sddm comments) I use lightdm and have never seen this issue.

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)

(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.

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

Apparently this fixed the issue. Feel free to re-open if the issue persists.

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

Still happening, nothing changed. I should also add that Battery plasmoid reports "No screen or keyboard brightness controls available.

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()).

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.

Created attachment 90766 [details]
Output from sudo sysprof now with Plasma 5.2 [Kubuntu Next Backports]

i have updated packages to 5.2 version and the issue is still there.

i can see it after screenlocker run as well.

Running 5.2, all the same here.

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/

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?

Can someone try this please 
https://git.reviewboard.kde.org/r/122307/

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 ()

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.

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 ()

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?

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

*** Bug 343542 has been marked as a duplicate of this bug. ***

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!

> 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).

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.

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.

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.

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.

This bug was fixed for 5.2.1, so there is no need to attach log files from 5.2.0.

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! :)

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

Please follow the steps from Comment #8.

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

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)

Created attachment 96116 [details]
kded5 cpu usage

Created attachment 96117 [details]
thread apply all bt

(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.

Can you check if you have 2 kded5 processes running?
Your backtrace again shows no activity at all.

(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%.

> 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.

Created attachment 96361 [details]
bt

And another bt...

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.

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...

(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.

(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.

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

Please check which kded module is responsible. You can disable them in the SystemSettings Service Manager.