When I'm using Qt Creator 3.3.0, after some time KWin freezes for a few minutes. Especially when I'm switching between several windows (ALT + TAB). Reproducible: Always
Actually I'm using KDE Plasma 5.2.0.
bug #340294 ? See https://bugs.kde.org/show_bug.cgi?id=340294#c21 and https://bugs.kde.org/show_bug.cgi?id=340294#c22
Well, I can't even check if my CPU goes up to 100%, because except moving the mouse, I can do absolute nothing. Next time, I can try to check CPU usage with CTRL + ESC, but I suppose, it won't react.
But so far I can tell, that the fan doesn't go up.
you can switch to a tty with ctrl+alt+f1- that should always work
bug #340294 also has a "patch" attached - you can simply override the present qml file w/ the attached one and "kwin_x11 --replace", though unless at least one core spikes, it's unlikely to be the same cause (just estimated from the alt+tab significance). Do you use the breeze style tabbox (left hand vertical) to begin with?
I use the default Breeze style. I can't reproduce the freeze so far... :-/
Ok, I could "reproduce" the bug. Qt Creator was minimized and in background for a few hours. Then, I just closed Konsole and KWin freezed. I pressed ALT + F2, logged into my account and run top. The result was, that kwin_x11 consumed ~ 102% CPU. I'm not sure, if Qt Creator is a factor for this bug, but I reckon, it was always running, when KWin freezed.
That's rather not the tabbox, I'd say. Next time this happens, please gdb into kwin_x11 echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope # this is to allow gdb to attach to the process gdb --pid `pidof kwin_x11` 2>&1 | tee kwin.gdb # runs and logs gdb into kwin.gdb in the gdb promt, issue bt and hit enter until the end of the stack is reached detach quit and attach kwin.gdb Alternatively, you may try to "pkill -11 kwin_x11" which should segfault KWin and trigger a DrKonqui dialog. Also please attach the output of qdbus org.kde.KWin /KWin supportInformation (now - the command won't work when kwin is frozen)
Created attachment 91198 [details] qdbus KWin supportInformation
Do you use glamor acceleration? grep -i glamor /var/log/Xorg.0.log
This command prints nothing, what would propably mean: no.
Created attachment 91203 [details] kwin.debug I installed kwin debug packages to provide some more information. I couldn't reproduce the bug for hours, but a few minutes ago, I had success. After beeing always in the same position of code, I detached gdb. I don't know, if this was a good idea.
You must call "continue" after taking a backtrace to allow the program to move forward (and possibly to another position) However, we're in the QtQuick land here and apparently on readoing the width of some item - which would rather support the tabbox theory? => Did you replace the tabbox qml with the fixed one from bug #340294 ? ------------------------ BACKTRACE ----------------------------- #0 0x00007f0e7103cdb4 in QQuickItem_widthRead (o=0x19a32b0, rv=0x7fffd8af2200) at /usr/src/debug/qtdeclarative-opensource-src-5.4.0/src/quick/items/qquickitem.cpp:112 #1 0x00007f0e70c9820b in Accessor (property=..., property=..., n=0x0, output=0x7fffd8af2200, object=0x19a32b0) at /usr/src/debug/qtdeclarative-opensource-src-5.4.0/src/qml/jsruntime/qv4qobjectwrapper.cpp:141 #2 LoadProperty<ReadAccessor::Accessor> (notifier=<optimized out>, property=..., object=0x19a32b0, engine=<optimized out>) at /usr/src/debug/qtdeclarative-opensource-src-5.4.0/src/qml/jsruntime/qv4qobjectwrapper.cpp:165 #3 QV4::QObjectWrapper::getProperty (object=0x19a32b0, ctx=<optimized out>, property=0x7f0e4405c798, captureRequired=<optimized out>) at /usr/src/debug/qtdeclarative-opensource-src-5.4.0/src/qml/jsruntime/qv4qobjectwrapper.cpp:364 #4 0x00007f0e70c98678 in QV4::QObjectWrapper::getProperty (object=<optimized out>, ctx=<optimized out>, propertyIndex=<optimized out>, captureRequired=<optimized out>) at /usr/src/debug/qtdeclarative-opensource-src-5.4.0/src/qml/jsruntime/qv4qobjectwrapper.cpp:633 #5 0x00007f0e70ca9bf0 in QV4::Runtime::getQmlQObjectProperty (ctx=<optimized out>, object=..., propertyIndex=<optimized out>, captureRequired=<optimized out>) at /usr/src/debug/qtdeclarative-opensource-src-5.4.0/src/qml/jsruntime/qv4runtime.cpp:1306 #6 0x00007f0e3da57c32 in ?? () #7 0x000000000187c928 in ?? () #8 0x00007f0e70cbb480 in QQmlVMEMetaObject::metaCall (this=0x7f0e5401c350, c=<optimized out>, _id=<optimized out>, a=<optimized out>) at /usr/src/debug/qtdeclarative-opensource-src-5.4.0/src/qml/qml/qqmlvmemetaobject.cpp:841 #9 0x00007f0e5401c350 in ?? () #10 0x00000000019a32b0 in ?? () #11 0x00007f0e4c51e1b8 in ?? () #12 0x0000000000000000 in ?? ()
No, I didn't apply the patch, because I wanted to trace the bug down first and I thought, the patch had been applied in KDE 5.2. I applied it know and restarted my laptop and we will see. :) Thx.
No freeze since I applied the patch.
Pre-emptively duping. Please re-open as soon as you encounter the freeze (despite the patched qml) *** This bug has been marked as a duplicate of bug 340294 ***