Bug 350327 - Snapping windows too fast freezes Plasma indefinitely
Summary: Snapping windows too fast freezes Plasma indefinitely
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: core (other bugs)
Version First Reported In: 5.2.2
Platform: Other Linux
: NOR crash
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2015-07-17 18:13 UTC by Allan
Modified: 2018-10-27 03:59 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Allan 2015-07-17 18:13:48 UTC
Snapping the windows repeatedly and quickly will freeze the UI.

This is easiest to reproduce with a touchscreen, but I have reproduced it with a trackpad as well.

I believe it is easier to reproduce with the default desktop effects (translucency enabled, maximize window) enabled, but I have reproduced it with all effects disabled.

Reproducible: Always

Steps to Reproduce:
1. Drag top bar to an edge to snap the window.
2. Repeat.
3. UI freezes.

Actual Results:  
UI freezes. If translucency is enabled, the window is stuck in a translucent state.
However, I can reproduce this without any desktop effects enabled.
Comment 1 Thomas Lübking 2015-07-17 19:23:46 UTC
- By "snapping" you mean "quick tiling"?
(can be toggled in "kcmshell5 kwinscreenedges", "tile by blahfoobar")
- How does the CPU react (100% load or calm)
- can you gdb into kwin to check where it hangs when this happens?
   (see https://community.kde.org/KWin/Debugging on how to gdb attach from VT1 or ssh)
Comment 2 Allan 2015-07-17 23:13:08 UTC
Yes, tiling, although I had it happen to me also just moving a window.
The CPU is calm.

I followed those gdb instructions but I am still having some issues.
Specifically,
in TTY1 as normal user,
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
gdb --pid `pidof kwin_x11` 2>&1 | tee kwin.gdb
continue
After 'continue', I go back into VT7 and my system is functional again. Once I get the crash, I go back into VT1.
I try 'bt' but I am unable to get any additional trace into kwin.gdb. Please advise how I can get the backtrace properly.
Comment 3 Thomas Lübking 2015-07-18 06:59:04 UTC
KWin did't exactly "crash", you'll have to interrupt it (press ctrl+c in gdb) in order to talk to gdb again (ie. issue "bt" to see the current stack)

Afterwards, you can either "kill" or "detach" the kwin process and "quit" gdb.
Comment 4 Martin Flöser 2016-09-02 12:18:56 UTC
Did you have any chance to get the backtrace of a frozen KWin instance?
Comment 5 Andrew Crouthamel 2018-09-26 22:10:20 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 6 Andrew Crouthamel 2018-10-27 03:59:18 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!