Bug 427502 - kwin_x11 often deadlocks when switching VTs
Summary: kwin_x11 often deadlocks when switching VTs
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.19.5
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-09 20:32 UTC by magiblot
Modified: 2021-10-29 17:32 UTC (History)
0 users

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 magiblot 2020-10-09 20:32:58 UTC
SUMMARY

When switching back and forth between VTs, kwin_x11 (not kwin_wayland) ends up being deadlocked.

The deadlock happens when switching from the tty or another graphical enviroment into Plasma X11.

By deadlock I mean that the screen stays frozen and that input devices are unresponsive. It is also not possible to force a VT switch with Magic SysRq and then Ctrl+Alt+Fn, or with chvt. For example, running `sudo chvt 3` via SSH results in the command blocking.

The whole session breaks after about 5 minutes of deadlock.

I also experienced, but I don't know if this is just a coincidence, that unplugging my input devices (USB mouse and keyboard via a USB hub) increases the chances of the deadlock going away before 5 minutes (with Plasma appearing on screen and input devices being responsive after a replug).

It may be also worth noting that I'm using a secondary display attached to my laptop, which has the lid closed.

STEPS TO REPRODUCE
1. Start a Plasma X11 session.
2. Switch to a tty.
3. Switch back to the initial Plasma X11 session.
4. Goto step 1 until you reproduce the issue.

OBSERVED RESULT

The system becomes unresponsive and it is not possible to switch VTs again until the X11 session times out or the deadlock goes away.

EXPECTED RESULT

It is possible to switch back and forth from other VTs without risking the system to become unresponsive.

SOFTWARE/OS VERSIONS

Operating System: Arch Linux
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.15.1
Kernel Version: 5.8.14-arch1-1
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-6200U CPU @ 2.30GHz
Graphics Processor: Mesa Intel® HD Graphics 520

ADDITIONAL INFORMATION

Here is a trace of kwin_x11 during one such deadlock:

> Thread 9 (Thread 0x7ff7b3fff640 (LWP 10026)):
> #0  0x00007ff7efae26a2 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0
> #1  0x00007ff7eff73fee in  () at /usr/lib/libQt5Script.so.5
> #2  0x00007ff7eff74019 in  () at /usr/lib/libQt5Script.so.5
> #3  0x00007ff7efadc3e9 in start_thread () at /usr/lib/libpthread.so.0
> #4  0x00007ff7f0283293 in clone () at /usr/lib/libc.so.6
> 
> Thread 8 (Thread 0x7ff7c93e1640 (LWP 10023)):
> #0  0x00007ff7efae26a2 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0
> #1  0x00007ff7e0c4d40c in  () at /usr/lib/dri/iris_dri.so
> #2  0x00007ff7e0c4d308 in  () at /usr/lib/dri/iris_dri.so
> #3  0x00007ff7efadc3e9 in start_thread () at /usr/lib/libpthread.so.0
> #4  0x00007ff7f0283293 in clone () at /usr/lib/libc.so.6
> 
> Thread 7 (Thread 0x7ff7c9be2640 (LWP 10022)):
> #0  0x00007ff7efae26a2 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0
> #1  0x00007ff7e0c4d40c in  () at /usr/lib/dri/iris_dri.so
> #2  0x00007ff7e0c4d308 in  () at /usr/lib/dri/iris_dri.so
> #3  0x00007ff7efadc3e9 in start_thread () at /usr/lib/libpthread.so.0
> #4  0x00007ff7f0283293 in clone () at /usr/lib/libc.so.6
> 
> Thread 6 (Thread 0x7ff7ca3e3640 (LWP 10021)):
> #0  0x00007ff7efae26a2 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0
> #1  0x00007ff7e0c4d40c in  () at /usr/lib/dri/iris_dri.so
> #2  0x00007ff7e0c4d308 in  () at /usr/lib/dri/iris_dri.so
> #3  0x00007ff7efadc3e9 in start_thread () at /usr/lib/libpthread.so.0
> #4  0x00007ff7f0283293 in clone () at /usr/lib/libc.so.6
> 
> Thread 5 (Thread 0x7ff7cabe4640 (LWP 10020)):
> #0  0x00007ff7efae26a2 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0
> #1  0x00007ff7e0c4d40c in  () at /usr/lib/dri/iris_dri.so
> #2  0x00007ff7e0c4d308 in  () at /usr/lib/dri/iris_dri.so
> #3  0x00007ff7efadc3e9 in start_thread () at /usr/lib/libpthread.so.0
> #4  0x00007ff7f0283293 in clone () at /usr/lib/libc.so.6
> 
> Thread 4 (Thread 0x7ff7e37fe640 (LWP 9951)):
> #0  0x00007ff7f027856e in ppoll () at /usr/lib/libc.so.6
> #1  0x00007ff7f085d8ab in qt_safe_poll(pollfd*, unsigned long, timespec const*) () at /usr/lib/libQt5Core.so.5
> #2  0x00007ff7f085efed in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
> #3  0x00007ff7f080765c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
> #4  0x00007ff7f0621ca2 in QThread::exec() () at /usr/lib/libQt5Core.so.5
> #5  0x00007ff7ef1074b9 in  () at /usr/lib/libQt5Qml.so.5
> #6  0x00007ff7f0622e8f in  () at /usr/lib/libQt5Core.so.5
> #7  0x00007ff7efadc3e9 in start_thread () at /usr/lib/libpthread.so.0
> #8  0x00007ff7f0283293 in clone () at /usr/lib/libc.so.6
> 
> Thread 3 (Thread 0x7ff7e9888640 (LWP 9881)):
> #0  0x00007ff7f027856e in ppoll () at /usr/lib/libc.so.6
> #1  0x00007ff7f085d8ab in qt_safe_poll(pollfd*, unsigned long, timespec const*) () at /usr/lib/libQt5Core.so.5
> #2  0x00007ff7f085efed in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
> #3  0x00007ff7f080765c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
> #4  0x00007ff7f0621ca2 in QThread::exec() () at /usr/lib/libQt5Core.so.5
> #5  0x00007ff7f190c098 in  () at /usr/lib/libQt5DBus.so.5
> #6  0x00007ff7f0622e8f in  () at /usr/lib/libQt5Core.so.5
> #7  0x00007ff7efadc3e9 in start_thread () at /usr/lib/libpthread.so.0
> #8  0x00007ff7f0283293 in clone () at /usr/lib/libc.so.6
> 
> Thread 2 (Thread 0x7ff7ea530640 (LWP 9880)):
> #0  0x00007ff7f027846f in poll () at /usr/lib/libc.so.6
> #1  0x00007ff7f053563b in poll (__timeout=-1, __nfds=1, __fds=0x7ff7ea52fbc8) at /usr/include/bits/poll2.h:46
> #2  _xcb_conn_wait (c=c@entry=0x563cc7d8e600, cond=cond@entry=0x563cc7d8e640, vector=vector@entry=0x0, count=count@entry=0x0) at xcb_conn.c:480
> #3  0x00007ff7f053737b in xcb_wait_for_event (c=0x563cc7d8e600) at xcb_in.c:697
> #4  0x00007ff7ea65ef61 in  () at /usr/lib/libQt5XcbQpa.so.5
> #5  0x00007ff7f0622e8f in  () at /usr/lib/libQt5Core.so.5
> #6  0x00007ff7efadc3e9 in start_thread () at /usr/lib/libpthread.so.0
> #7  0x00007ff7f0283293 in clone () at /usr/lib/libc.so.6
> 
> Thread 1 (Thread 0x7ff7ead7ccc0 (LWP 9876)):
> #0  0x00007ff7efae26a2 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0
> #1  0x00007ff7f0535819 in _xcb_conn_wait (c=c@entry=0x563cc7d8e600, cond=cond@entry=0x7fff0319d020, vector=vector@entry=0x0, count=count@entry=0x0) at xcb_conn.c:448
> #2  0x00007ff7f053708f in wait_for_reply (c=c@entry=0x563cc7d8e600, request=16299, e=e@entry=0x0) at xcb_in.c:516
> #3  0x00007ff7f05371a2 in xcb_wait_for_reply (c=0x563cc7d8e600, request=16299, e=0x0) at xcb_in.c:532
> #4  0x00007ff7ea66944a in QXcbConnection::xi2HandleDeviceChangedEvent(void*) () at /usr/lib/libQt5XcbQpa.so.5
> #5  0x00007ff7ea63b84f in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) () at /usr/lib/libQt5XcbQpa.so.5
> #6  0x00007ff7ea63cc69 in QXcbConnection::processXcbEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5XcbQpa.so.5
> #7  0x00007ff7ea66037e in  () at /usr/lib/libQt5XcbQpa.so.5
> #8  0x00007ff7f080765c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
> #9  0x00007ff7f080faf4 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5
> #10 0x0000563cc7132412 in main(int, char**) (argc=<optimized out>, argv=0x7fff0319d4f8) at /usr/src/debug/kwin-5.19.5/main_x11.cpp:479
Comment 1 magiblot 2021-10-29 17:32:55 UTC
I haven't experienced this issue in a while. Using Plasma 5.22.5.