| Summary: | plasmashell freezes and consumes 100% of the CPU | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | P. Varet <p.varet> |
| Component: | general | Assignee: | David Edmundson <kde> |
| Status: | CLOSED FIXED | ||
| Severity: | crash | CC: | 3ndymion, anakin.cs, barry, bhush94, brian, bugzylittle, cedric.borgese, christiandehne, codestruct, fademind, gerd, hashbang173, joe.christy, joe.yasi, jospoortvliet, kare.sars, kde, kolAflash, lbeltrame, loic.yhuel, luis.davila.pc, mathieu, plasma-bugs, randy, rdieter, reuben_p, s.hs, stupor_scurvy343, t-mo, travneff, zanetu |
| Priority: | NOR | Keywords: | drkonqi |
| Version: | 5.3.0 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/kdeplasma-addons/e32a705bcca843b71fa5a43defd2d0630cb2f810 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
Backtrace
Trigger broken dataengine patch that stops the crash for me testcase qml file |
||
|
Description
P. Varet
2015-05-29 08:49:27 UTC
Do you have any of the system load applets (the ones with the animating graphs of resource usage) on your desktop? (In reply to David Edmundson from comment #1) > Do you have any of the system load applets (the ones with the animating > graphs of resource usage) on your desktop? I just reproduced the issue, with the "System Load Viewer" applet in the panel. m_sourceItem is a QQuickShaderEffect, by looking at the shaders it seems it comes from a LinearGradient. m_sourceItem->width() is 11 m_sourceItem->height() is 5.0792036951891379e+17 => qCeil(qAbs(sourceRect.height())) overflows to -2147483648, and the loops runs forever *hugs* thank you so much for spotting that. Should be much much easier to fix now. *** Bug 345696 has been marked as a duplicate of this bug. *** (In reply to David Edmundson from comment #4) > *** Bug 345696 has been marked as a duplicate of this bug. *** I this case, plasmashell is completely frozen, as it's an infinite loop. Do you think the other bug is caused by a big height, but not enough to cause overflows (and smaller than maximum texture size too) ? https://bugs.kde.org/show_bug.cgi?id=346134 might also be related. Git commit f399aa8b48db02f809454be5427c0ca01b809882 by David Edmundson. Committed on 08/07/2015 at 13:54. Pushed by davidedmundson into branch 'master'. Only resize plot texture if size actually changes Test compared rounded QSize with QSizeF, which will be almost always returning true. REVIEW: 124280 M +6 -7 src/qmlcontrols/kquickcontrolsaddons/plotter.cpp http://commits.kde.org/kdeclarative/f399aa8b48db02f809454be5427c0ca01b809882 Good news:) is this patch relevant for the monitor applets CPU leak? Is this part of the next Plasma release? I don't think this fix is /the/ fix which is why I've left this open. It's just something I noticed when looking into what Loïc Yhuel said. In data Friday 17 July 2015 13:23:52, hai scritto:
> I don't think this fix is /the/ fix which is why I've left this open.
> It's just something I noticed when looking into what Loïc Yhuel said.
According to what normart said earlier in this bug, the way to fix this
properly is to use event compression.
(In reply to Luca Beltrame from comment #10) > According to what normart said earlier in this bug, the way to fix this > properly is to use event compression. Event compression would help when the CPU usage is high, but not in this case, where plasmashell is frozen (in an infinite loop). Git commit 7a6a2cda780784e504960c96b4b41241ddf10531 by David Edmundson. Committed on 27/07/2015 at 10:54. Pushed by davidedmundson into branch 'master'. Don't refresh the entire window when we render the plotter This means the window is only updated when the plotter changes, rather than effectively every possible frame. Reviewed by: Marco Martin M +0 -3 src/qmlcontrols/kquickcontrolsaddons/plotter.cpp http://commits.kde.org/kdeclarative/7a6a2cda780784e504960c96b4b41241ddf10531 [13:16] <Lekensteyn> d___ed: confirmed that the CPU usage is normal, render is called for a reasonable number of times I'm going to optimistically assume this is fixed for 5.13 Please, please test and report back. Confirmed that kdeclarative commit 7a6a2cda780784e504960c96b4b41241ddf10531 fixes the CPU usage. Tested with RAM and CPU monitors (separately). Before this patch the Plotter::render() function would be called an insanely amount of times (125 times per second). After this patch, it is only called once (for each Plotter::addSample -> Plotter::updatePaintMode). *** Bug 350573 has been marked as a duplicate of this bug. *** (In reply to David Edmundson from comment #12) > Git commit 7a6a2cda780784e504960c96b4b41241ddf10531 by David Edmundson. > Committed on 27/07/2015 at 10:54. > Pushed by davidedmundson into branch 'master'. > > Don't refresh the entire window when we render the plotter > > This means the window is only updated when the plotter changes, rather > than effectively every possible frame. > > Reviewed by: Marco Martin > > M +0 -3 src/qmlcontrols/kquickcontrolsaddons/plotter.cpp > > http://commits.kde.org/kdeclarative/7a6a2cda780784e504960c96b4b41241ddf10531 Guys... I just wanted to say thanks for this. For the past week or 2, I have noticed that the CPU on my laptop is not going crazy & burning up anymore, even with widgets active. Now, it actually stays under 1% when idle, just the way it should be. I was wondering if the bug, bug 345696 , was silently fixed somehow, & now I see that it was fixed. I've only been using Linux for a couple of years now, but I am very frustrated with the things that go on in the world of Linux... things constantly don't work... things constantly don't get fixed... it's so annoying. This has caused me to learn all I can & start building a program of my own for the world to use. Now that my laptop is not burning up anymore, I can finally work with peace of heart, & I'm sure many other people as well. So seriously guys... thanks so much for this. It's very much appreciated. : ) I just reproduced the original issue on 5.4.1 (but it's probably much more random now). Same problem : infinite loop in QQuickShaderEffectSource::updatePaintNode, since m_sourceItem->height() is 5.0792036951891379e+17 Ah comment #2 said something about height being exteme too. The thing I fixed was a constant redrawing, yet kinda usable. I think we may have two bugs on our hands with similar symptoms. I don't know if it's related, but the qFuzzyCompare(adjustedMax - adjustedMin, 0) in Plotter::normalizeData probably doesn't work, as the Qt doc states : "Note that comparing values where either p1 or p2 is 0.0 will not work. The solution to this is to compare against values greater than or equal to 1.0." Created attachment 94604 [details]
Backtrace
Seems to be the same problem for me. Does not appear to be tied to anything quite in particular. It happens within minutes of starting the computer. I have completely uninstalled, reinstalled plasma, deleted all my configurations, started from scratch. Tested other graphics drivers to make sure the issue wasn't a configuration error on my side.
Hopefully my back trace can be useful. When the crash occurs anything else running still runs but eventually the entire screen locks up and I can only move the mouse. So the desktop goes black, all the side bars disappear, I can still alt-tab and lock my screen but the rest of what I believe is the plasma shell is inaccessible.
(In reply to Brian Logan from comment #20) > Created attachment 94604 [details] > Backtrace It seems to be an actual crash, not a plasmashell freeze with 100% CPU. @Brian, I think that's unrelated. I have seen that trace elsewhere though so we don't need to make a new bug @Loïc Yhuel Thanks for the qFuzzyCompare comments, that's useful but QQuickShaderEffectSource isn't used in the plotter Places that use it are : WidgetExplorer Kicker Dashboard SystemLoadViewer Compact Bar Monitor (In reply to David Edmundson from comment #23) > SystemLoadViewer Compact Bar Monitor This is the one I'm using (and probably the original reporter too since the callstacks are the same), see comment 2. I thought the plotter fixes were related, since reproducing the issue is now much harder, but it seems it's really random. it'll be the systemloadviewer compact bar monitor...
height: barBorder.height * barMonitor.proportions[index]
proportions coming from SystemLoadViewer.qml
proportions should be between 0 and 1, however it must have a divide by zero in there when it does:
proprtion = current/max
code that we have in SystemLoadViewer.qml.
I have a patch that will probably fix it:
--- a/applets/systemloadviewer/package/contents/ui/CompactBarMonitor.qml
+++ b/applets/systemloadviewer/package/contents/ui/CompactBarMonitor.qml
@@ -43,7 +43,7 @@ Item {
model: proportions.length
Rectangle {
color: barMonitor.colors[index]
- height: barBorder.height * barMonitor.proportions[index]
+ height: barBorder.height * Math.max(barMonitor.proportions[index],1)
width: barBorder.width
anchors {
bottom: index == 0 ? barBorder.bottom : barRepeater.itemAt(index-1).top
(END)
but I'd rather get to the bottom of this if we can. The datasource must be reporting some bogus results somewhere.
(In reply to David Edmundson from comment #25) > - height: barBorder.height * barMonitor.proportions[index] > + height: barBorder.height * > Math.max(barMonitor.proportions[index],1) Math.min > > but I'd rather get to the bottom of this if we can. The datasource must be > reporting some bogus results somewhere. Tell me if I can help. Looking in SystemLoadViewer.qml, I see a few parseFloat() calls, which would return NaN if the dataSource reports something unexpected. I don't know what it would do when set to height. Would you be able to run with this patch for a while, then hopefully we'll see which entry is failing. https://paste.kde.org/pq7xyq53q in the meantime I'll take a code review of the dataengine and look for anything possibly related. Here is a gdb session from what I think is an instance of this bug.
I have plasma-workspace-5.4.1-3.fc22.x86_64 installed.
It shows a problem "while loop" stuck at:
qquickshadereffectsource.cpp:637 and 638
You can see that the height being doubled is 0x80000000 and each time its value stays the same.
(gdb) bt 5
#0 0x00007f32c8a2a198 in QQuickShaderEffectSource::updatePaintNode(QSGNode*, QQuickItem::UpdatePaintNodeData*) (this=0x2157d20, oldNode=0x7f31f03f0a20) at /usr/src/debug/qtdeclarative-opensource-src-5.5.0/src/quick/items/qquickshadereffectsource.cpp:638
#1 0x00007f32c8940850 in QQuickWindowPrivate::updateDirtyNode(QQuickItem*) (this=this@entry=0x19d92b0, item=item@entry=0x2157d20)
at /usr/src/debug/qtdeclarative-opensource-src-5.5.0/src/quick/items/qquickwindow.cpp:2985
#2 0x00007f32c89410ab in QQuickWindowPrivate::updateDirtyNodes() (this=this@entry=0x19d92b0)
at /usr/src/debug/qtdeclarative-opensource-src-5.5.0/src/quick/items/qquickwindow.cpp:2723
#3 0x00007f32c8941220 in QQuickWindowPrivate::syncSceneGraph() (this=0x19d92b0)
at /usr/src/debug/qtdeclarative-opensource-src-5.5.0/src/quick/items/qquickwindow.cpp:341
#4 0x00007f32c8912c13 in QSGRenderThread::sync(bool) (this=this@entry=0x27f3e10, inExpose=<optimized out>)
at /usr/src/debug/qtdeclarative-opensource-src-5.5.0/src/quick/scenegraph/qsgthreadedrenderloop.cpp:512
#5 0x00007f32c8913e55 in QSGRenderThread::syncAndRender() (this=this@entry=0x27f3e10)
at /usr/src/debug/qtdeclarative-opensource-src-5.5.0/src/quick/scenegraph/qsgthreadedrenderloop.cpp:558
(gdb) n
637 while (textureSize.height() < minTextureSize.height())
(gdb)
638 textureSize.rheight() *= 2;
(gdb)
637 while (textureSize.height() < minTextureSize.height())
(gdb) p textureSize
$1 = {wd = 21, ht = -2147483648}
(gdb) p minTextureSize
$2 = {wd = 1, ht = <optimized out>}
(gdb) p minTextureSize
$3 = {wd = 1, ht = <optimized out>}
(gdb) p textureSize.ht
$5 = -2147483648
(gdb) p/x textureSize.ht
$6 = 0x80000000
(gdb) n
638 textureSize.rheight() *= 2;
(gdb)
637 while (textureSize.height() < minTextureSize.height())
(gdb)
638 textureSize.rheight() *= 2;
(gdb)
637 while (textureSize.height() < minTextureSize.height())
(gdb)
638 textureSize.rheight() *= 2;
(gdb)
637 while (textureSize.height() < minTextureSize.height())
(gdb) p/x textureSize.ht
$7 = 0x80000000
(gdb)
Thanks, that matches the evaluation above. Could you run with the patch at #27? Thanks for tracking this down, guys, Plasma invariably uses 100% cpu after being up for a day or two. Of course, so does Firefox so I'm not sure what to yell at for making the fan of my computer blow like it's in the middle of a heat wave... ;-) But, combined with KRunner frequently getting slow as ass, this takes care of my last gripes with Plasma 5.x so awesome work! (In reply to David Edmundson from comment #29) > Thanks, that matches the evaluation above. Could you run with the patch at > #27? I'm Running the patch. Where does console.log output to so that I can check for the error messages? stderr so either ~/.xsession-errors or the shell you started plasmashell from if you started it by hand Sorry the patch does not help. I see exactly the same looping in the plasmashell. Why not patch the code that is looping to detect the bad input condition and error out? Either crash or report the error. Isn't better then allow a DoS on plasmashell by using poorly written qml? I did see these messages: file:///usr/share/plasma/plasmoids/org.kde.plasma.systemloadviewer/contents/ui/SystemLoadViewer.qml:153: TypeError: Cannot read property 'value' of undefined file:///usr/share/plasma/plasmoids/org.kde.plasma.systemloadviewer/contents/ui/SystemLoadViewer.qml:67: TypeError: Cannot read property of null file:///usr/share/plasma/plasmoids/org.kde.plasma.systemloadviewer/contents/ui/SystemLoadViewer.qml:181: TypeError: Cannot read property 'value' of undefined file:///usr/share/plasma/plasmoids/org.kde.plasma.systemloadviewer/contents/ui/SystemLoadViewer.qml:181: TypeError: Cannot read property 'value' of undefined file:///usr/share/plasma/plasmoids/org.kde.plasma.systemloadviewer/contents/ui/SystemLoadViewer.qml:192: TypeError: Cannot read property 'value' of undefined file:///usr/share/plasma/plasmoids/org.kde.plasma.systemloadviewer/contents/ui/SystemLoadViewer.qml:181: TypeError: Cannot read property 'value' of undefined (In reply to Barry Scott from comment #33) > Sorry the patch does not help. I see exactly the same looping in the > plasmashell. The patch is there to try to understand which values are wrong. > > Why not patch the code that is looping to detect the bad input condition and > error out? > Either crash or report the error. Isn't better then allow a DoS on > plasmashell by using poorly > written qml? I agree QQuickShaderEffectSource should fail in these cases (width/height too big), perhaps we should create a Qt bug for this. > > I did see these messages: > file:///usr/share/plasma/plasmoids/org.kde.plasma.systemloadviewer/contents/ > ui/SystemLoadViewer.qml:153: TypeError: Cannot read property 'value' of > undefined > file:///usr/share/plasma/plasmoids/org.kde.plasma.systemloadviewer/contents/ > ui/SystemLoadViewer.qml:67: TypeError: Cannot read property of null > file:///usr/share/plasma/plasmoids/org.kde.plasma.systemloadviewer/contents/ > ui/SystemLoadViewer.qml:181: TypeError: Cannot read property 'value' of > undefined > file:///usr/share/plasma/plasmoids/org.kde.plasma.systemloadviewer/contents/ > ui/SystemLoadViewer.qml:181: TypeError: Cannot read property 'value' of > undefined > file:///usr/share/plasma/plasmoids/org.kde.plasma.systemloadviewer/contents/ > ui/SystemLoadViewer.qml:192: TypeError: Cannot read property 'value' of > undefined > file:///usr/share/plasma/plasmoids/org.kde.plasma.systemloadviewer/contents/ > ui/SystemLoadViewer.qml:181: TypeError: Cannot read property 'value' of > undefined I have those too, but on startup, so (at least in my case) they are not related to this issue. I didn't reproduce the freeze since I added the patch. (In reply to Loïc Yhuel from comment #34) > (In reply to Barry Scott from comment #33) > > Sorry the patch does not help. I see exactly the same looping in the > > plasmashell. > The patch is there to try to understand which values are wrong. > > > > Why not patch the code that is looping to detect the bad input condition and > > error out? > > Either crash or report the error. Isn't better then allow a DoS on > > plasmashell by using poorly > > written qml? > I agree QQuickShaderEffectSource should fail in these cases (width/height > too big), perhaps we should create a Qt bug for this. If one of the plasmashell developers can come up with a patch to catch this bug early I will happily run with it and report back findings. I seem to be able to trigger this once or twice a day (I do not not know how). I would need to know how to identify the code triggering the error detection. If you can print that into the logs great, otherwise how can I find that answer with gdb? Created attachment 94795 [details]
Trigger broken dataengine
Attached QML file shows that we can get NaNs whilst the engine connects.
I'll add a shoddy guard in the QML for 5.4.2, then for 5.5 I'm rewriting this garbage with a proper import where we have types done properly.
Git commit 564b06d32c2e7c581f2316342854881b08788809 by David Edmundson. Committed on 01/10/2015 at 11:26. Pushed by davidedmundson into branch 'Plasma/5.4'. Fix system loadviewer results SystemLoadViewer Dataengine gives us undefined values at startup. We need an immediate fix in Plasma stable so check bad values on the JS side. M +10 -3 applets/systemloadviewer/package/contents/ui/SystemLoadViewer.qml http://commits.kde.org/kdeplasma-addons/564b06d32c2e7c581f2316342854881b08788809 Are you sure it will fix the issue ? The freeze doesn't happen on startup when the engine connects. I'm 80% confident. Let me know if it doesn't. I am running with your updated SystemLoadViewer.qml from http://commits.kde.org/kdeplasma-addons/564b06d32c2e7c581f2316342854881b08788809 It does not fix the problem. I still see the hang in the same place. I just had the freeze again on 5.4.2. Created attachment 95040 [details] patch that stops the crash for me Hi, When I apply this patch on top of the patch in https://git.reviewboard.kde.org/r/125006/ I no-longer get the crash in system-load-viewer. I applied this patch half a week ago and no crashes since then. Before this patch I would get the crash ~every 30min. Note: I'm using the compact bars. The review does not touch this file except increasing the number of bars (I have compiled and installed just the systemloadviewer from kdeplasma-addons master on top of Kubuntu packages of Plasma 5.3) "bottomMargin: index == 0 ? barBorder.border.width : 0" the line above should also be removed as barBorder is no longer a Rectangle and besides the border was always 0... @David: In https://bugs.kde.org/show_bug.cgi?id=354126#c14 you wrote that you need some more info. I'm experiencing the problem with 5.4.2, so your patch from Comment 37 above is already applied. What exactly do you want me to try? The patch Kåre posted which removes the LinearGradient? obviously removing the gradient will fix it in #42 I will do that as a last resort for 5.4.3 if we don't have something better However, that's definitely not a proper fix and it just hides the cause. Created attachment 95106 [details]
testcase qml file
Can people who have this run
qmlscene thisfilq.qml
it should list the values the bar chart is using. using the same code.
If this says NaN or Infinity or something like 2034982034980435 then let me know.
(In reply to David Edmundson from comment #46) > Can people who have this run > > qmlscene thisfilq.qml > > it should list the values the bar chart is using. using the same code. Directly after I started it, it wrote to the shell: file:///home/gerd/tmp/tmpd/testcase.qml:74: TypeError: Cannot read property 'value' of undefined file:///home/gerd/tmp/tmpd/testcase.qml:74: TypeError: Cannot read property 'value' of undefined file:///home/gerd/tmp/tmpd/testcase.qml:74: TypeError: Cannot read property 'value' of undefined file:///home/gerd/tmp/tmpd/testcase.qml:81: TypeError: Cannot read property 'value' of undefined Afterwards it looks like this is not working as expected: I ran your qml for some hours. plasmashell (with system load viewer and compact bar) froze two times during that time, but your qml didn't output anything on the shell I started it on or in it's window. Hi, I modified the CompactBarMonitor.qml to print out barMonitor.proportions[] if one of the values where NaN, < 0 or >10000. After a couple of minutes I got: plasmashell(0x7d7610) expression for height 55: !!!!!!!!!!!!!!!!!!!!!!!!!!!!! 186330739112222400 186330739112222400 4 plasmashell(0x7d7610) expression for height 57: prop 0 = 0.010101009999999999 plasmashell(0x7d7610) expression for height 57: prop 1 = 0.040404039999999995 plasmashell(0x7d7610) expression for height 57: prop 2 = 0 plasmashell(0x7d7610) expression for height 57: prop 3 = 186330739112222400 The "prop 3" stands for ioWait: dataSource.data[ "cpu/cpu" + cpuIndex + "/wait"] /Kåre (In reply to Kåre Särs from comment #48) > Hi, > > I modified the CompactBarMonitor.qml to print out barMonitor.proportions[] > if one of the values where NaN, < 0 or >10000. > > After a couple of minutes I got: > plasmashell(0x7d7610) expression for height 55: > !!!!!!!!!!!!!!!!!!!!!!!!!!!!! 186330739112222400 186330739112222400 4 > plasmashell(0x7d7610) expression for height 57: prop 0 = 0.010101009999999999 > plasmashell(0x7d7610) expression for height 57: prop 1 = 0.040404039999999995 > plasmashell(0x7d7610) expression for height 57: prop 2 = 0 > plasmashell(0x7d7610) expression for height 57: prop 3 = 186330739112222400 > > The "prop 3" stands for ioWait: dataSource.data[ "cpu/cpu" + cpuIndex + > "/wait"] Any idea why you do not see the "value" errors that Gerd and I have seen with the original script? Would you mind explaining how you got it to output messages and where are they logged? Barry I have a similar issue with Plasma 5.4.2 on ArchLinux. plasmashell is currently using 100% CPU, and even goes to 120% from time to time. This gets my laptop quite hot and the fans make a lot of noise. I can't find any errors in .xsession-errors or journalctl though. Here's a backtrace, if it's of any use: Thread 9 (Thread 0x7f428be19700 (LWP 1501)): #0 0x00007f429c28d18d in poll () from /usr/lib/libc.so.6 #1 0x00007f42a12c4ae2 in ?? () from /usr/lib/libxcb.so.1 #2 0x00007f42a12c6757 in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #3 0x00007f428d539e89 in ?? () from /usr/lib/libQt5XcbQpa.so.5 #4 0x00007f429c98e96e in ?? () from /usr/lib/libQt5Core.so.5 #5 0x00007f429ba954a4 in start_thread () from /usr/lib/libpthread.so.0 #6 0x00007f429c29613d in clone () from /usr/lib/libc.so.6 Thread 8 (Thread 0x7f42891db700 (LWP 1588)): #0 0x00007f429c28d18d in poll () from /usr/lib/libc.so.6 #1 0x00007f429873dfbc in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007f429873e0cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007f429cbc634f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #4 0x00007f429cb6d37a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #5 0x00007f429c9899c4 in QThread::exec() () from /usr/lib/libQt5Core.so.5 #6 0x00007f429fd3fc85 in ?? () from /usr/lib/libQt5Qml.so.5 #7 0x00007f429c98e96e in ?? () from /usr/lib/libQt5Core.so.5 #8 0x00007f429ba954a4 in start_thread () from /usr/lib/libpthread.so.0 #9 0x00007f429c29613d in clone () from /usr/lib/libc.so.6 Thread 7 (Thread 0x7f42780f7700 (LWP 1591)): #0 0x00007f429c28d18d in poll () from /usr/lib/libc.so.6 #1 0x00007f429873dfbc in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007f429873e0cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007f429cbc634f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #4 0x00007f429cb6d37a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #5 0x00007f429c9899c4 in QThread::exec() () from /usr/lib/libQt5Core.so.5 #6 0x00007f429fd3fc85 in ?? () from /usr/lib/libQt5Qml.so.5 #7 0x00007f429c98e96e in ?? () from /usr/lib/libQt5Core.so.5 #8 0x00007f429ba954a4 in start_thread () from /usr/lib/libpthread.so.0 #9 0x00007f429c29613d in clone () from /usr/lib/libc.so.6 Thread 6 (Thread 0x7f4276508700 (LWP 1595)): #0 0x00007f429c28d18d in poll () from /usr/lib/libc.so.6 #1 0x00007f429873dfbc in ?? () from /usr/lib/libglib-2.0.so.0 ---Type <return> to continue, or q <return> to quit--- #2 0x00007f429873e0cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007f429cbc634f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #4 0x00007f429cb6d37a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #5 0x00007f429c9899c4 in QThread::exec() () from /usr/lib/libQt5Core.so.5 #6 0x00007f429fd3fc85 in ?? () from /usr/lib/libQt5Qml.so.5 #7 0x00007f429c98e96e in ?? () from /usr/lib/libQt5Core.so.5 #8 0x00007f429ba954a4 in start_thread () from /usr/lib/libpthread.so.0 #9 0x00007f429c29613d in clone () from /usr/lib/libc.so.6 Thread 5 (Thread 0x7f4274bdc700 (LWP 1597)): #0 0x00007f429ba9b07f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x00007f42a255f5e4 in ?? () from /usr/lib/libQt5Script.so.5 #2 0x00007f42a255f629 in ?? () from /usr/lib/libQt5Script.so.5 #3 0x00007f429ba954a4 in start_thread () from /usr/lib/libpthread.so.0 #4 0x00007f429c29613d in clone () from /usr/lib/libc.so.6 Thread 4 (Thread 0x7f426df8e700 (LWP 1598)): #0 0x00007f429c28d18d in poll () from /usr/lib/libc.so.6 #1 0x00007f429873dfbc in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007f429873e0cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007f429cbc636b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #4 0x00007f429cb6d37a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #5 0x00007f429c9899c4 in QThread::exec() () from /usr/lib/libQt5Core.so.5 #6 0x00007f42a08f8486 in ?? () from /usr/lib/libQt5Quick.so.5 #7 0x00007f429c98e96e in ?? () from /usr/lib/libQt5Core.so.5 #8 0x00007f429ba954a4 in start_thread () from /usr/lib/libpthread.so.0 #9 0x00007f429c29613d in clone () from /usr/lib/libc.so.6 Thread 3 (Thread 0x7f41e0514700 (LWP 1681)): #0 0x00007f429c28d18d in poll () from /usr/lib/libc.so.6 #1 0x00007f429873dfbc in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007f429873e0cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007f429cbc634f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #4 0x00007f429cb6d37a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #5 0x00007f429c9899c4 in QThread::exec() () from /usr/lib/libQt5Core.so.5 #6 0x00007f41e0d7a9f5 in ?? () from /usr/lib/qt/qml/QtQuick/XmlListModel/libqmlxmllistmodelplugin.so #7 0x00007f429c98e96e in ?? () from /usr/lib/libQt5Core.so.5 ---Type <return> to continue, or q <return> to quit--- #8 0x00007f429ba954a4 in start_thread () from /usr/lib/libpthread.so.0 #9 0x00007f429c29613d in clone () from /usr/lib/libc.so.6 Thread 2 (Thread 0x7f41dfb0b700 (LWP 1682)): #0 0x00007f429c28d18d in poll () from /usr/lib/libc.so.6 #1 0x00007f429873dfbc in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007f429873e0cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007f429cbc634f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #4 0x00007f429cb6d37a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #5 0x00007f429c9899c4 in QThread::exec() () from /usr/lib/libQt5Core.so.5 #6 0x00007f429c98e96e in ?? () from /usr/lib/libQt5Core.so.5 #7 0x00007f429ba954a4 in start_thread () from /usr/lib/libpthread.so.0 #8 0x00007f429c29613d in clone () from /usr/lib/libc.so.6 Thread 1 (Thread 0x7f42a2dca800 (LWP 1497)): #0 0x00007f429c28d18d in poll () from /usr/lib/libc.so.6 #1 0x00007f429873dfbc in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007f429873e0cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007f429cbc634f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #4 0x00007f429cb6d37a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #5 0x00007f429cb7533c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5 #6 0x00000000004300f3 in main () This is apparently caused by the octopi-notifier icon for me, when it has updates to display. If I kill the octopi-notifier process, plasmashell usage goes back to 0%. Starting it again make it go back to 100%. Hi, I let the computer run over night and now in the morning it had failed when the dataengine returned an insanely high value for "ioWait". I think the JS workaround would be to also add a check that the value returned by fitCpuLoad() is not over 1 (and maybe also not under 0). I had missed that the infinite loop only happened with QQuickShaderEffect items ;) Barry: I stopped plasmashell and started it from Konsole and then the output goes to the Konsole output AnAkkk: I think that is a separate issue that I see that you already reported to arch :) Git commit 351c2a03827040d148a1b73dbeab12eb3d3e69de by Kåre Särs. Committed on 29/10/2015 at 07:21. Pushed by sars into branch 'master'. Fix SystemLoadViewer freezing plasmashell REVIEW: 125858 M +3 -3 applets/systemloadviewer/package/contents/ui/SystemLoadViewer.qml http://commits.kde.org/kdeplasma-addons/351c2a03827040d148a1b73dbeab12eb3d3e69de Git commit e32a705bcca843b71fa5a43defd2d0630cb2f810 by Kåre Särs. Committed on 29/10/2015 at 12:28. Pushed by sars into branch 'Plasma/5.4'. Fix SystemLoadViewer freezing plasmashell REVIEW: 125858 M +3 -3 applets/systemloadviewer/package/contents/ui/SystemLoadViewer.qml http://commits.kde.org/kdeplasma-addons/e32a705bcca843b71fa5a43defd2d0630cb2f810 *** Bug 354675 has been marked as a duplicate of this bug. *** |