Bug 340294

please try to attach gdb to it when it happens and generate a backtrace.

please also attach the output of
   qdbus org.kde.KWin /KWin supportInformation

also see bug #338355 (is it related to adding a window, inc. even tooltips and such?)

Below I attach the kwin support info. I don't know how to use gdb, or what to do to obtain a useful bug report when the system is frozen. Any hint appreciated. It seems not to be related to adding windows etc, it appears random to me.

Created attachment 89373 [details]
KWin support information

what's the output of "grep -i glamor /var/log/Xorg.0.log"?

On gdb:

[press Ctrl+Alt+F1]
[login]
# this will allow you to attach gdb to kwin
$ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
# run gdb, log to "kwin.gdb"
$  gdb --pid `pidof kwin` 2>&1 | tee kwin.gdb
# you're not in the gdb promt ">"
> bt
[enter, enter, enter, ... until there's no more output]
> detach
> quit
$ exit
[press Ctrl+Alt+F7]

without the requested output we won't be able to investigate this.

(In reply to Martin Gräßlin from comment #6)
> without the requested output we won't be able to investigate this.

Unfortunately, I switched back to plasma 4, so that I cannot provide further reports on this.

thanks for getting back to us. That's totally fine to switch back to 4.x :-)

I'll change to WORKSFORME as that's what it is at the moment. If you switch to 5.x again and still are experiencing this problem, please reopen.

I'm using a Plasma 5 desktop compiled from sources (as a side note: for KMyMoney frameworks development) and I encountered this kwin issue, as I remember, several times after pressing Alt+Tab. Today, after building the sources, I've started the session again and it happened while working and using Alt+Tab. Plasma became unusable so I switched to a VT and attached with gdb to obtain a stack trace. I'll attach it to this report. I'll also reopen the issue to reflect this new information.

Created attachment 90567 [details]
KWin stack trace while process is at 100% CPU

As promised, this is the stack trace obtained using gdb.

hard to say from one trace for sure, but looks like a recursive gepmetry update in QtQuick.
Which switcher style do you use?

Created attachment 90568 [details]
The switcher I use

This is the switcher I use, let me know if I can get more data than the stack trace next time this happens.

Can you please look up the actual name in "kcmshell5 kwintabbox"?
(It looks like "Thumbnails" but there're alternative variants to this)

Created attachment 90572 [details]
I was using the "Breeze" switcher

Actually I just realized that killing kwin and restarting it by hand changed the window decorations to oxygen and the window switcher, so forget the previous screenshot, this is what Plasma was using by default. It's the "Breeze" switcher, I just realized this after logging back into the Plasma 5 session.

Created attachment 90573 [details]
Another gdb stack trace

This happened again today.

From the second trace and a brief look at the qml, i'd say that Plasma.ScrollArea cannot decide whether it wants a scrollbar or not.

What would happen is that the list has a height just a little larger than then scrollarea, the area adds a scrollbar. In return the available width and thus all items (with somewhat fixed aspect) shrink. As a result the list is shorter than the scrollarea. The scrollbar is not required and removed. More width, so the icons grow ...

Adding Marco.
Autohiding scrollbars are recursion prone and this needs at least a decision where to be fixed (ie. how idiot-proof PlasmaExtras.ScrollArea is supposed to be)

Also: do we need a PlasmaExtras.ScrollArea (ie. scrollbars) here at all??

I'm glad that the second trace provided more information :).

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

hey. bug 343260 has much longer backtraces of kwin and kded, with over 200 calls on the stack )))

scrollbars would be redundant, because the switching is done by keyboard and not the mouse.

(In reply to Nick Shaforostoff from comment #20)
> scrollbars would be redundant, because the switching is done by keyboard and
> not the mouse.

I assume it's to indicate the padding.

Can you try to replace it with the attached file?
Should go somewhere like
usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/windowswitcher/WindowSwitcher.qml

Created attachment 90656 [details]
WindowSwitcher.qml with width depending on scrollbar visability

yes, this fixes the issue. but still, the scrollbar is visually a redundant detail for me.

for example on osx scrollbars are becoming visible only while mouse cursor is close to the right or bottom window edge

Consulting HIG ;-)

@Thomas P.
Please ignore the scary backtraces.
The opened question is whether the window switcher should indicate the oversupply of windows (by showing a scrollbar)

Having some kind of indicator of
a) The fact that there are more windows than are being shown in the list
b) Which section of the overall list is currently visible
is important here because if we don't show any indication, users will wonder where those other windows are gone.

The scrollbar has the advantage that it's well known, but if its technical problems can't be solved on the technical level, it's okay to use a different indicator for the above two kinds of information.

a nicer looking indicator would be small arrows on the bottom and top of the vertical bar

Git commit 116b1d170eb25b957a3c0f3d21b429afc3f88d6a by Nick Shaforostoff.
Committed on 27/01/2015 at 01:53.
Pushed by shaforo into branch 'master'.

fix total system freeze on some systems like my 10 inch netbook
thanks Thomas Lübking for providing the patch

M  +2    -1    lookandfeel/contents/windowswitcher/WindowSwitcher.qml

http://commits.kde.org/plasma-workspace/116b1d170eb25b957a3c0f3d21b429afc3f88d6a

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

Nick, did you also chery-pick that for 5.2?

i will do it later this evening

Git commit 30c0bcd017f2f5db2f0578e06c095b54e156422b by Nick Shaforostoff.
Committed on 27/01/2015 at 01:53.
Pushed by shaforo into branch 'Plasma/5.2'.

fix total system freeze on some systems like my 10 inch netbook
thanks Thomas Lübking for providing the patch

M  +2    -1    lookandfeel/contents/windowswitcher/WindowSwitcher.qml

http://commits.kde.org/plasma-workspace/30c0bcd017f2f5db2f0578e06c095b54e156422b

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

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

Created attachment 94040 [details]
kwin_x11 stacktrace when cpu usage is high and visual artefacts are showing

Stack trace of kwin_x11 taken when high CPU usage and visual artefacts are observed.

I seem to observe the same behavior with AMD fglrx driver on R9 280X.
OpenSuSE 13.2, KF5 5.3.95

completely unrelated.

the aurorae decoration, or rather qtquick, triggers a framebuffer read and that stirs up something deep in fglrx.

switch to the breeze decoration, but the problem will be either in  qtquick or fglrx.

You're probably right, the problem might be in fglrx, as switching to breeze didn't help. I'll try restart later, check if that would help.

I want to try to switch to open-source driver for R9 280x. Does somebody know about major issues of doing so?

kwin_x11 constantly uses 100% CPU for the other users when using multi login <Ctrl-Alt-Fn>. That is A logged in to F7, B logged in to F8 and C logged in through F9. When A is using the system B's and C's kwin_x11 uses 100% CPU. When B is using the system A's and C's CPU usage is at 100% and so on.

Completely unrelated to this bug, the driver waits for a vblank signal that never occurs, suspend the compositor on the inactive VTs.

See bug #328122 or bug #330954

I confirm, I use multilogon and unused logon user use 100% cpu kwin_x11. 
Plasma 5.7.4, (S 5.25.0), QT 5.7.0