Bug 429845 - Kwin locks up and have to kill it from TTY to recover.
Summary: Kwin locks up and have to kill it from TTY to recover.
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: general (other bugs)
Version First Reported In: 5.25.5
Platform: Fedora RPMs Linux
: NOR crash
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-30 11:45 UTC by Jasmijn Emilia Rosalina Knoope
Modified: 2022-12-07 05:12 UTC (History)
2 users (show)

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


Attachments
Video of this crash, see description ADDITIONAL INFORMATION. (3.83 MB, video/mp4)
2020-11-30 11:45 UTC, Jasmijn Emilia Rosalina Knoope
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jasmijn Emilia Rosalina Knoope 2020-11-30 11:45:31 UTC
Created attachment 133749 [details]
Video of this crash, see description ADDITIONAL INFORMATION.

SUMMARY
Kwin complete lockup when holding a window + using "Window to Previous/Next Desktop" shortcut.

STEPS TO REPRODUCE
1. Hold a window by holding down kwin modifier key (in my case Meta) or window decoration
2. Hold "Window to Previous/Next Desktop" shortcut (in my case Meta + Shift + W/S, at this step I have not presses W/S yet)
3. Press shortcut "Switch to Previous/Next Desktop" (in my case Meta + W/S, I press W/S now, but the previous two shortcuts then overlap)

OBSERVED RESULT

Window does get dragged along to the desktop, but kwin completely locks up, I can not interact with any windows, opening krunner works but I can not type in it, I have to switch to another TTY and kill the kwin_x11 process, I can then type in krunner to restart it.

EXPECTED RESULT
Same behavior as holding window with the modifier key (Not "Window to Previous/Next Desktop" shortcut, shift in my case) and changing desktops with "Switch to Previous/Next Desktop" shortcut. This would drag the window along with the desktop. The "Window to Previous/Next Desktop" shortcut is designed to do this, but without holding the window, if you do hold the window this lockup happens. It should negate the "Window to Previous/Next Desktop" shortcut if you are holding a window because "Switch to Previous/Next Desktop" already has the correct behavior.

Operating System: Gentoo Linux
KDE Plasma Version: 5.20.3
KDE Frameworks Version: 5.76.0
Qt Version: 5.15.2
Kernel Version: 5.9.11-gentoo
OS Type: 64-bit
Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor
Memory: 15.6 GiB of RAM
Graphics Processor: AMD Radeon ™ RX 470 Graphics

ADDITIONAL INFORMATION
In the first part of the video you see me using the "Window to Previous/Next Desktop" shortcut (Meta + Shift + W/S).
Then I hold Meta to grab the window and use the "Switch to Previous/Next Desktop" shortcut (Meta + W/S) to drag the window to the other desktop, this works.
Then I combine the two and use "Window to Previous/Next Desktop" shortcut while holding the window, this crashes kwin. I then open krunner and demonstrate I can not type in it, I switch to another TTY and kill kwin_x11 and restart it with krunner.

This is pretty niche and seems like a lot of conditions, but this happens frequently, these shortcuts I believe are logical and I doubt I am the only one to have them set like this, in any case, this shouldn't crash kwin.
Comment 1 Justin Zobel 2022-10-31 04:33:27 UTC
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 2 Jasmijn Emilia Rosalina Knoope 2022-11-07 21:16:48 UTC
I was just able to replicate this on Fedora 36 with Plasma/kwin 5.25.5. Restarting kwin_x11 with the `kwin_x11 --replace` command still fixes the issue, but it has to be killed from a different TTY or a SSH session since all windows become uninteractable.
Comment 3 Jasmijn Emilia Rosalina Knoope 2022-11-07 21:31:15 UTC
The same does not happen for the "Window to previous/next screen" shortcut, so it's not just using shortcuts that move a window while it's held, it's specific to changing it's desktop.
It can also be caused by using the move button in the window more actions.

More concise steps to reproduce:
1. Either:
  Hold a window by holding down kwin modifier key (in my case Meta) or window decoration
  Right click a window's window decoration. Under "More" click "Move".
2. Press shortcut for "Switch to Previous/Next Desktop". This isn't bound by default.

Attempting to switch the window to a different desktop like this while it's being dragged around causes kwin to crash.

In my case the shortcuts for switching desktops and moving a window to a different desktop overlap, so I think the window should just come with the cursor. When those shortcuts don't overlap, I think it should just let go of the window since it's going to be on a different desktop than the active view.
Comment 4 David Edmundson 2022-11-07 22:21:05 UTC
This is not universally reproducible.

Can you reproduce, switch to a TTY and run

sudo gdb --pid `pidof kwin_x11`

then it connects type "set logging on" "bt"

it will dump a file called gdb.txt in the current directory
Comment 5 Jasmijn Emilia Rosalina Knoope 2022-11-07 22:26:00 UTC
(In reply to David Edmundson from comment #4)
> This is not universally reproducible.
> 
> Can you reproduce, switch to a TTY and run
> 
> sudo gdb --pid `pidof kwin_x11`
> 
> then it connects type "set logging on" "bt"
> 
> it will dump a file called gdb.txt in the current directory

I'm not seeing any output that's different than the normal output after replicating it. 

[Inferior 1 (process 2786944) detached]
#0  0x00007f0cfc25598e in ppoll () at /lib64/libc.so.6
#1  0x00007f0cfd625280 in qt_safe_poll(pollfd*, unsigned long, timespec const*) ()
    at /lib64/libQt5Core.so.5
#2  0x00007f0cfd626796 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
    () at /lib64/libQt5Core.so.5
#3  0x00007f0ce9df4c92 in QXcbUnixEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5XcbQpa.so.5
#4  0x00007f0cfd5d6c1a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
    at /lib64/libQt5Core.so.5
#5  0x00007f0cfd5dece2 in QCoreApplication::exec() () at /lib64/libQt5Core.so.5
#6  0x000055c70f6172e1 in main ()
Quit
Comment 6 Bug Janitor Service 2022-11-22 05:12:51 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
mark the bug 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 7 Bug Janitor Service 2022-12-07 05:12:26 UTC
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!