when gdb has done all it's lib loading and presents you a promt, please enter "bt" to get a backtrace.

Same problem as me. See kf5 doesn't work.

Oops - here we go:

Code: Select all

 (gdb) bt
#0  0x00007fedeb05d160 in KSGRD::SensorAgent::sendRequest(QString const&, KSGRD::SensorClient*, int) () from /usr/lib64/libksgrd.so.5
#1  0x00007fedeb0648c2 in KSGRD::SensorManager::sendRequest(QString const&, QString const&, KSGRD::SensorClient*, int) () from /usr/lib64/libksgrd.so.5
#2  0x00007fedeb2aa06a in SystemMonitorEngine::answerReceived (this=0x7ec6350, id=<optimized out>, answer=...)
    at /var/tmp/portage/kde-base/plasma-workspace-5.0.0/work/plasma-workspace-5.0.0/dataengines/systemmonitor/systemmonitor.cpp:167
#3  0x00007fedeb05d8a0 in KSGRD::SensorAgent::processAnswer(char const*, int) () from /usr/lib64/libksgrd.so.5
#4  0x00007fedeb0659c0 in ?? () from /usr/lib64/libksgrd.so.5
#5  0x00007fef21d74bd9 in QMetaObject::activate (sender=sender@entry=0x7f20c10, signalOffset=<optimized out>, local_signal_index=local_signal_index@entry=5,
    argv=argv@entry=0x0) at kernel/qobject.cpp:3680
#6  0x00007fef21d750f7 in QMetaObject::activate (sender=sender@entry=0x7f20c10, m=m@entry=0x7fef22179200 <QProcess::staticMetaObject>,
    local_signal_index=local_signal_index@entry=5, argv=argv@entry=0x0) at kernel/qobject.cpp:3546
#7  0x00007fef21c6f0b3 in QProcess::readyReadStandardOutput (this=this@entry=0x7f20c10) at .moc/moc_qprocess.cpp:269
#8  0x00007fef21c71ddd in QProcessPrivate::tryReadFromChannel (this=0x7605980, channel=0x7605ac8) at io/qprocess.cpp:967
#9  0x00007fef21c72215 in _q_canReadStandardError (this=<optimized out>) at io/qprocess.cpp:986
#10 QProcess::qt_static_metacall (_o=<optimized out>, _c=<optimized out>, _id=<optimized out>, _a=0x7fff81ff4fe0) at .moc/moc_qprocess.cpp:137
#11 0x00007fef21d74bd9 in QMetaObject::activate (sender=sender@entry=0x8378170, signalOffset=<optimized out>, local_signal_index=local_signal_index@entry=0,
    argv=argv@entry=0x7fff81ff4fe0) at kernel/qobject.cpp:3680
#12 0x00007fef21d750f7 in QMetaObject::activate (sender=sender@entry=0x8378170, m=m@entry=0x7fef2217e700 <QSocketNotifier::staticMetaObject>,
    local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7fff81ff4fe0) at kernel/qobject.cpp:3546
#13 0x00007fef21df5a6e in QSocketNotifier::activated (this=this@entry=0x8378170, _t1=101) at .moc/moc_qsocketnotifier.cpp:132
#14 0x00007fef21d81f00 in QSocketNotifier::event (this=0x8378170, e=0x7fff81ff5300) at kernel/qsocketnotifier.cpp:300
#15 0x00007fef229d797c in QApplicationPrivate::notify_helper (this=this@entry=0x2560d60, receiver=receiver@entry=0x8378170, e=e@entry=0x7fff81ff5300)
    at kernel/qapplication.cpp:3522
---Type <return> to continue, or q <return> to quit---
#16 0x00007fef229dc980 in QApplication::notify (this=0x7fff81ff56a0, receiver=0x8378170, e=0x7fff81ff5300) at kernel/qapplication.cpp:3305
#17 0x00007fef21d44acd in QCoreApplication::notifyInternal (this=0x7fff81ff56a0, receiver=0x8378170, event=event@entry=0x7fff81ff5300) at kernel/qcoreapplication.cpp:935
#18 0x00007fef21d9eb34 in sendEvent (event=0x7fff81ff5300, receiver=<optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:237
#19 socketNotifierSourceDispatch (source=0x259fa50) at kernel/qeventdispatcher_glib.cpp:109
#20 0x00007fef1bec6df6 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#21 0x00007fef1bec7148 in ?? () from /usr/lib64/libglib-2.0.so.0
#22 0x00007fef1bec71ec in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#23 0x00007fef21d9dbbc in QEventDispatcherGlib::processEvents (this=0x259a880, flags=...) at kernel/qeventdispatcher_glib.cpp:426
#24 0x00007fef21d4290b in QEventLoop::exec (this=this@entry=0x7fff81ff5540, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212
#25 0x00007fef21d4a31f in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1188
#26 0x00007fef22269cac in QGuiApplication::exec () at kernel/qguiapplication.cpp:1450
#27 0x00007fef229d60a5 in QApplication::exec () at kernel/qapplication.cpp:2767
#28 0x0000000000433bb0 in main (argc=1, argv=<optimized out>) at /var/tmp/portage/kde-base/plasma-workspace-5.0.0/work/plasma-workspace-5.0.0/shell/main.cpp:109

Is ksysguard5 running? Does anything change if you kill it (if it's running) or if you run it (if it's not running)?

ksysguard5? I have a binary /usr/bin/ksysguard, which is the system monitor, but that's not what you're talking about, right?
If so, no. I use ksysguard most of the time to kill plasmashell, I never noticed any change in behaviour.

Is this ksysguard the 4.x version, or the 5.x version?

It's 5.0.0. 4.x isn't installed.

Bump!
I install Arch and plasma-next on my laptop and have this issue too.
All time plasmashell process have 20-30% CPU usage.
Here my ~/.xsession-errors http://pastebin.com/XMRiRNQe

Bounce!

This will likely be some plasmoid - the backtrace suggest some sensor/cpumonitor/whatever banging ksysguardd[5] (notice the double "dd", trailing version name is probably optional)

You could try to remove such (and afterwards other) plasmoids to narrow the culprit.
But the only way to get a real information about what causes CPU load is called "valgrind" (--tool callgrind) - or any other profiler

I haven't had much time recently to look into the problem - but it seems to be getting worse with every update. I'm now at a point where I have to restart plasmashell every 5 minutes. I'm just running it from the terminal so I can hit CTRL+C, UPARROW, ENTER every now and then. I'm using just the standard layout, no additional applets or anything. All I changed was the font and the wallpaper.

This issue seems to be triggered by plasma-nm. Whenever plasma-nm is busy connecting to the network, the "busy" animation will hog the CPU. Since due to some other bug, my laptop tries to connect to Ethernet after a couple of suspends (and never fails or succeeds to connect, just keeps trying), I have a constant "busy" animation. IIRC this is some known bug with intel graphics cards... Once I hit the "disconnect" button, CPU load drops after a couple of seconds.

Yes, this is triggered by plasma-nm, but it's a bug somewhere else. See bug 336274.

Looks like this issue haven't been handled properly until now. I still have this problem on my up-to-date ArchLinux with main version of KDE packages being 5.3.0-3, Linux kernel is 4.0.1-1
BUT I don't have plasma-nm running when CPU load climbs high. I have this problem every time I start my session for a while. I haven't installed or enabled much plugins. The most frequently used programs would be Kmail and google-chrome.
Kwallet prompt for password now and again. I don't like kmail and kwallet for this reason.

zoulu wrote:Looks like this issue haven't been handled properly until now. I still have this problem on my up-to-date ArchLinux with main version of KDE packages being 5.3.0-3, Linux kernel is 4.0.1-1
BUT I don't have plasma-nm running when CPU load climbs high. I have this problem every time I start my session for a while. I haven't installed or enabled much plugins. The most frequently used programs would be Kmail and google-chrome.
Kwallet prompt for password now and again. I don't like kmail and kwallet for this reason.

This is quite the same setup and usage scenario, I have and I have the CPU-Load Issue, too.

I'm too using Arch Linux with these Plasma packages installed:

Code: Select all

plasma-desktop 5.3.0-3
plasma-framework 5.10.0-1
plasma-mediacenter 5.3.0-3
plasma-nm 5.3.0-3
plasma-workspace 5.3.0-3

I'm using near exclusive the following applications:

• Chromium
• Konsole
• Thunderbird
• Kate
• Kwallet

It's my problem too with Fedora 22 and KDE Frameworks 5.10. Do someone needs some additional information to solve that bug?