I am running fc34 with zawertun copr repos enabled (newest plasma releases, also updates-testing enabled) and when trying to enter the wayland desktop, the DE background shows for a short time and dies immediately. This happens several times in a row (switching between DE-background and vconsole) until it gives up and shows the login screen again. Using plasma with x11 is fine, btw. I attached an excerpt of the journalctl output, it seems that kwin crashes Any idea what can be done to address this problem (and what further data is needed to analyze this?) The system is an i5 with integrated intel graphics with a 4k displayPort attached monitor. The wayland desktop was running properly with fc33 (plasma 5.21 or similar), but i didn't test it further at that time. Just saying, the DE was usable and did not crash, but i switched back to x11 then. === Process 3325 (kwin_wayland) of user 10001 dumped core. Stack trace of thread 3325: #0 0x00007f219354cc01 _ZN4KWin27KeyboardLayoutDBusInterface18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv (libkwin.so.5 + 0xfac01) #1 0x00007f219354cf43 _ZN4KWin27KeyboardLayoutDBusInterface11qt_metacallEN11QMetaObject4CallEiPPv (libkwin.so.5 + 0xfaf43) Jul 18 22:33:08 m910x audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@0-3768-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Jul 18 22:33:08 m910x akonadi_followupreminder_agent[3731]: The Wayland connection broke. Did the Wayland compositor die? Jul 18 22:33:08 m910x klauncher[3606]: The Wayland connection broke. Did the Wayland compositor die? Jul 18 22:33:08 m910x kded5[3365]: The Wayland connection broke. Did the Wayland compositor die? Jul 18 22:33:08 m910x plasmashell[3392]: kf.plasma.quick: The compositor does not support the plasma shell protocol Jul 18 22:33:08 m910x org_kde_powerdevil[3429]: The Wayland connection broke. Did the Wayland compositor die? Jul 18 22:33:08 m910x xdg-desktop-portal-kde[3750]: The Wayland connection broke. Did the Wayland compositor die? Jul 18 22:33:08 m910x korgac[3591]: The Wayland connection broke. Did the Wayland compositor die? Jul 18 22:33:08 m910x seapplet[3563]: Error reading events from display: Broken pipe Core Dump (PID 4187/UID 0). Jul 18 22:33:11 m910x systemd-coredump[4191]: [🡕] Process 4183 (xembedsniproxy) of user 10001 dumped core. Process 4180 (gmenudbusmenupr) of user 10001 dumped core.
Can you please check coredumps for a backtrace?
Created attachment 140177 [details] coredump-1
Created attachment 140178 [details] coredump-2
i added the first two coredumps, hope this is what you were looking for
I don't think that I'll be able to open them on my computer. Could you please use gdb to get backtraces in text form?
Created attachment 140179 [details] dump-bt
hmm... like that?
pasting inline #0 0x00007f219354cc01 in KWin::KeyboardLayoutDBusInterface::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () from /lib64/libkwin.so.5 #1 0x00007f219354cf43 in KWin::KeyboardLayoutDBusInterface::qt_metacall(QMetaObject::Call, int, void**) () from /lib64/libkwin.so.5 #2 0x00007f21937f722b in QDBusConnectionPrivate::deliverCall(QObject*, int, QDBusMessage const&, QVector<int> const&, int) () from /lib64/libQt5DBus.so.5 #3 0x00007f21937fac7c in QDBusConnectionPrivate::activateCall(QObject*, int, QDBusMessage const&) [clone .part.0] () from /lib64/libQt5DBus.so.5 #4 0x00007f21937fb50d in QDBusConnectionPrivate::activateObject(QDBusConnectionPrivate::ObjectTreeNode&, QDBusMessage const&, int) () from /lib64/libQt5DBus.so.5 Did we speak in the past about how you had some quirky issues with DBus that were caused by use of musl and setcap?
> Did we speak in the past about how you had some quirky issues with DBus that were caused by use of musl and setcap? Sorry, no, wasn't me. This fedora34 installation is not deviating from standard (updates included), i played with podman/cgroup hierarchies, but not with musl on this machine. fc34 uses glibc as default Regarding keyboard: maybe just on slight thing that comes to my mind: i added a remapping of caps-lock to control key in a separate mapping file which is loaded / added with localctl In plasma, there is a separate caps to control mapping, but i also want it for vconsole. Could this interfere somehow?
Newest updates to fedora34, still the same nasty bug when trying to start a wayland session Out of ideas, how to fix this: Any help? ==== Sep 12 12:05:36 m910x systemd-coredump[3606]: Process 3167 (kwin_wayland) of user 10001 dumped core. Stack trace of thread 3167: #0 0x00007f6b2423ec81 _ZN4KWin27KeyboardLayoutDBusInterface18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv (libkwin.so.5 + 0xfbc81) #1 0x00007f6b2423efc3 _ZN4KWin27KeyboardLayoutDBusInterface11qt_metacallEN11QMetaObject4CallEiPPv (libkwin.so.5 + 0xfbfc3) #2 0x00007f6b244e91eb _ZN22QDBusConnectionPrivate11deliverCallEP7QObjectiRK12QDBusMessageRK7QVectorIiEi (libQt5DBus.so.5 + 0x281eb) #3 0x00007f6b244ecc3c _ZN22QDBusConnectionPrivate12activateCallEP7QObjectiRK12QDBusMessage.part.0 (libQt5DBus.so.5 + 0x2bc3c) #4 0x00007f6b244ed4cd _ZN22QDBusConnectionPrivate14activateObjectERNS_14ObjectTreeNodeERK12QDBusMessagei (libQt5DBus.so.5 + 0x2c4cd) #5 0x00007f6b244ef9fc _ZN24QDBusActivateObjectEvent13placeMetaCallEP7QObject (libQt5DBus.so.5 + 0x2e9fc) #6 0x00007f6b2292ef09 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2d0f09) #7 0x00007f6b2357e443 _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5 + 0x1ae443) #8 0x00007f6b22904798 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5 + 0x2a6798) #9 0x00007f6b22907d06 _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData (libQt5Core.so.5 + 0x2a9d06) #10 0x00007f6b22953075 _ZN20QEventDispatcherUNIX13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2f5075) #11 0x0000556b495989a1 _ZN23QUnixEventDispatcherQPA13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (kwin_wayland + 0x8f9a1) #12 0x00007f6b229031a2 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2a51a2) #13 0x00007f6b2290b6e4 _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x2ad6e4) #14 0x0000556b4953b1e9 main (kwin_wayland + 0x321e9) #15 0x00007f6b22070b75 __libc_start_main (libc.so.6 + 0x27b75) #16 0x0000556b4953baee _start (kwin_wayland + 0x32aee) Stack trace of thread 3172: #0 0x00007f6b2213e5bf __poll (libc.so.6 + 0xf55bf) #1 0x00007f6b200c348c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa948c) #2 0x00007f6b2006cc03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03) #3 0x00007f6b22955b78 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2f7b78) #4 0x00007f6b229031a2 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2a51a2) #5 0x00007f6b227462aa _ZN7QThread4execEv (libQt5Core.so.5 + 0xe82aa) #6 0x00007f6b244dcb6b _ZN22QDBusConnectionManager3runEv (libQt5DBus.so.5 + 0x1bb6b) #7 0x00007f6b227474a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6) #8 0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299) #9 0x00007f6b22149353 __clone (libc.so.6 + 0x100353) Stack trace of thread 3175: #0 0x00007f6b2213e5bf __poll (libc.so.6 + 0xf55bf) #1 0x00007f6b200c348c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa948c) #2 0x00007f6b2006cc03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03) #3 0x00007f6b22955b78 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2f7b78) #4 0x00007f6b229031a2 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2a51a2) #5 0x00007f6b227462aa _ZN7QThread4execEv (libQt5Core.so.5 + 0xe82aa) #6 0x00007f6b227474a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6) #7 0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299) #8 0x00007f6b22149353 __clone (libc.so.6 + 0x100353) Stack trace of thread 3176: #0 0x00007f6b2213e5bf __poll (libc.so.6 + 0xf55bf) #1 0x00007f6b200c348c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa948c) #2 0x00007f6b2006cc03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03) #3 0x00007f6b22955b78 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2f7b78) #4 0x00007f6b229031a2 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2a51a2) #5 0x00007f6b227462aa _ZN7QThread4execEv (libQt5Core.so.5 + 0xe82aa) #6 0x00007f6b227474a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6) #7 0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299) #8 0x00007f6b22149353 __clone (libc.so.6 + 0x100353) Stack trace of thread 3177: #0 0x00007f6b2251da8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f6b225172c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0) #2 0x00007f6afe84142b util_queue_thread_func (iris_dri.so + 0x1b942b) #3 0x00007f6afe840eeb impl_thrd_routine (iris_dri.so + 0x1b8eeb) #4 0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f6b22149353 __clone (libc.so.6 + 0x100353) Stack trace of thread 3178: #0 0x00007f6b2251da8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f6b225172c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0) #2 0x00007f6afe84142b util_queue_thread_func (iris_dri.so + 0x1b942b) #3 0x00007f6afe840eeb impl_thrd_routine (iris_dri.so + 0x1b8eeb) #4 0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f6b22149353 __clone (libc.so.6 + 0x100353) Stack trace of thread 3179: #0 0x00007f6b2251da8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f6b225172c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0) #2 0x00007f6afe84142b util_queue_thread_func (iris_dri.so + 0x1b942b) #3 0x00007f6afe840eeb impl_thrd_routine (iris_dri.so + 0x1b8eeb) #4 0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f6b22149353 __clone (libc.so.6 + 0x100353) Stack trace of thread 3180: #0 0x00007f6b2251da8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f6b225172c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0) #2 0x00007f6afe84142b util_queue_thread_func (iris_dri.so + 0x1b942b) #3 0x00007f6afe840eeb impl_thrd_routine (iris_dri.so + 0x1b8eeb) #4 0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f6b22149353 __clone (libc.so.6 + 0x100353) Stack trace of thread 3181: #0 0x00007f6b2251da8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f6b225172c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0) #2 0x00007f6afe84142b util_queue_thread_func (iris_dri.so + 0x1b942b) #3 0x00007f6afe840eeb impl_thrd_routine (iris_dri.so + 0x1b8eeb) #4 0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f6b22149353 __clone (libc.so.6 + 0x100353) Stack trace of thread 3182: #0 0x00007f6b2251da8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f6b225172c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0) #2 0x00007f6afe84142b util_queue_thread_func (iris_dri.so + 0x1b942b) #3 0x00007f6afe840eeb impl_thrd_routine (iris_dri.so + 0x1b8eeb) #4 0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f6b22149353 __clone (libc.so.6 + 0x100353) Stack trace of thread 3186: #0 0x00007f6b2251da8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f6b225175c4 pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf5c4) #2 0x00007f6b2274cf7a _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt5Core.so.5 + 0xeef7a) #3 0x00007f6b2274a774 _ZN17QThreadPoolThread3runEv (libQt5Core.so.5 + 0xec774) #4 0x00007f6b227474a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6) #5 0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299) #6 0x00007f6b22149353 __clone (libc.so.6 + 0x100353) Stack trace of thread 3183: #0 0x00007f6b2251da8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f6b225175c4 pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf5c4) #2 0x00007f6b2274cf7a _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt5Core.so.5 + 0xeef7a) #3 0x00007f6b2274a774 _ZN17QThreadPoolThread3runEv (libQt5Core.so.5 + 0xec774) #4 0x00007f6b227474a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6) #5 0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299) #6 0x00007f6b22149353 __clone (libc.so.6 + 0x100353) Stack trace of thread 3184: #0 0x00007f6b2213e5bf __poll (libc.so.6 + 0xf55bf) #1 0x00007f6b200c348c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa948c) #2 0x00007f6b2006cc03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03) #3 0x00007f6b22955b78 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2f7b78) #4 0x00007f6b229031a2 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2a51a2) #5 0x00007f6b227462aa _ZN7QThread4execEv (libQt5Core.so.5 + 0xe82aa) #6 0x00007f6b2139c5ec _ZN17QQmlThreadPrivate3runEv (libQt5Qml.so.5 + 0x2d45ec) #7 0x00007f6b227474a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6) #8 0x00007f6b22511299 start_thread (libpthread.so.0 + 0x9299) #9 0x00007f6b22149353 __clone (libc.so.6 + 0x100353)
Hi, please try to update to latest kwin: 5.22.5. Looks like you're using old version. Could you also paste there KDE version info from kinfocenter?
P.S. Run `sudo dnf up --refresh` to update to latest version.
It seems like a temporary problem of that particular copr repo, we can't reproduce it now. Please update and report back again.
Hi all, i just upgraded the installation, now i'm on plasma 5.22.5, kf5-... 5.86.0 Still the same problem. After the login screen (wayland), the plasma desktop seems to show up, i see my background (plain color) and mousecursor. Before any panels are drawn on the screen, it crashes and goes in the already known loop (until giving up) X11 works as it should, by the way. What additional info can i provide to handle this particular problem?
Oct 06 16:20:19 m910x systemd-coredump[4573]: [🡕] Process 4205 (kwin_wayland) of user 10001 dumped core. Stack trace of thread 4205: #0 0x00007f01fdbb8c81 _ZN4KWin27KeyboardLayoutDBusInterface18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv (libkwin.so.5 + 0xfbc81) #1 0x00007f01fdbb8fc3 _ZN4KWin27KeyboardLayoutDBusInterface11qt_metacallEN11QMetaObject4CallEiPPv (libkwin.so.5 + 0xfbfc3) #2 0x00007f01fde631eb _ZN22QDBusConnectionPrivate11deliverCallEP7QObjectiRK12QDBusMessageRK7QVectorIiEi (libQt5DBus.so.5 + 0x281eb) #3 0x00007f01fde66c3c _ZN22QDBusConnectionPrivate12activateCallEP7QObjectiRK12QDBusMessage.part.0 (libQt5DBus.so.5 + 0x2bc3c) #4 0x00007f01fde674cd _ZN22QDBusConnectionPrivate14activateObjectERNS_14ObjectTreeNodeERK12QDBusMessagei (libQt5DBus.so.5 + 0x2c4cd) #7 0x00007f01fc0b64a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6) #8 0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299) #9 0x00007f01fbaad353 __clone (libc.so.6 + 0x100353) Stack trace of thread 4209: #0 0x00007f01fbaa25bf __poll (libc.so.6 + 0xf55bf) #1 0x00007f01f9a1e48c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa948c) #2 0x00007f01f99c7c03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03) #3 0x00007f01fc2c4b78 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2f7b78) #4 0x00007f01fc2721a2 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2a51a2) #5 0x00007f01fc0b52aa _ZN7QThread4execEv (libQt5Core.so.5 + 0xe82aa) #6 0x00007f01fc0b64a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6) #7 0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299) #8 0x00007f01fbaad353 __clone (libc.so.6 + 0x100353) Stack trace of thread 4210: #0 0x00007f01fbaa25bf __poll (libc.so.6 + 0xf55bf) #1 0x00007f01f9a1e48c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa948c) #2 0x00007f01f99c7c03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03) #3 0x00007f01fc2c4b78 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2f7b78) #4 0x00007f01fc2721a2 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2a51a2) #5 0x00007f01fc0b52aa _ZN7QThread4execEv (libQt5Core.so.5 + 0xe82aa) #6 0x00007f01fc0b64a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6) #7 0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299) #8 0x00007f01fbaad353 __clone (libc.so.6 + 0x100353) Stack trace of thread 4211: #0 0x00007f01fbe8ca8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f01fbe862c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0) #2 0x00007f01e0e2f42b util_queue_thread_func (iris_dri.so + 0x1b942b) #3 0x00007f01e0e2eeeb impl_thrd_routine (iris_dri.so + 0x1b8eeb) #4 0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f01fbaad353 __clone (libc.so.6 + 0x100353) Stack trace of thread 4212: #0 0x00007f01fbe8ca8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f01fbe862c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0) #2 0x00007f01e0e2f42b util_queue_thread_func (iris_dri.so + 0x1b942b) #3 0x00007f01e0e2eeeb impl_thrd_routine (iris_dri.so + 0x1b8eeb) #4 0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f01fbaad353 __clone (libc.so.6 + 0x100353) Stack trace of thread 4213: #0 0x00007f01fbe8ca8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f01fbe862c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0) #2 0x00007f01e0e2f42b util_queue_thread_func (iris_dri.so + 0x1b942b) #3 0x00007f01e0e2eeeb impl_thrd_routine (iris_dri.so + 0x1b8eeb) #4 0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f01fbaad353 __clone (libc.so.6 + 0x100353) Stack trace of thread 4214: #0 0x00007f01fbe8ca8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f01fbe862c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0) #2 0x00007f01e0e2f42b util_queue_thread_func (iris_dri.so + 0x1b942b) #3 0x00007f01e0e2eeeb impl_thrd_routine (iris_dri.so + 0x1b8eeb) #4 0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f01fbaad353 __clone (libc.so.6 + 0x100353) Stack trace of thread 4215: #0 0x00007f01fbe8ca8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f01fbe862c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0) #2 0x00007f01e0e2f42b util_queue_thread_func (iris_dri.so + 0x1b942b) #3 0x00007f01e0e2eeeb impl_thrd_routine (iris_dri.so + 0x1b8eeb) #4 0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f01fbaad353 __clone (libc.so.6 + 0x100353) Stack trace of thread 4216: #0 0x00007f01fbe8ca8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f01fbe862c0 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf2c0) #2 0x00007f01e0e2f42b util_queue_thread_func (iris_dri.so + 0x1b942b) #3 0x00007f01e0e2eeeb impl_thrd_routine (iris_dri.so + 0x1b8eeb) #4 0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f01fbaad353 __clone (libc.so.6 + 0x100353) Stack trace of thread 4217: #0 0x00007f01fbe8ca8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f01fbe865c4 pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf5c4) #2 0x00007f01fc0bbf7a _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt5Core.so.5 + 0xeef7a) #3 0x00007f01fc0b9774 _ZN17QThreadPoolThread3runEv (libQt5Core.so.5 + 0xec774) #4 0x00007f01fc0b64a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6) #5 0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299) #6 0x00007f01fbaad353 __clone (libc.so.6 + 0x100353) Stack trace of thread 4221: #0 0x00007f01fbaa25bf __poll (libc.so.6 + 0xf55bf) #1 0x00007f01f9a1e48c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa948c) #2 0x00007f01f99c7c03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03) #3 0x00007f01fc2c4b78 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2f7b78) #4 0x00007f01fc2721a2 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2a51a2) #5 0x00007f01fc0b52aa _ZN7QThread4execEv (libQt5Core.so.5 + 0xe82aa) #6 0x00007f01facff5ec _ZN17QQmlThreadPrivate3runEv (libQt5Qml.so.5 + 0x2d45ec) #7 0x00007f01fc0b64a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6) #8 0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299) #9 0x00007f01fbaad353 __clone (libc.so.6 + 0x100353) Stack trace of thread 4223: #0 0x00007f01fbe8ca8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f01fbe865c4 pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf5c4) #2 0x00007f01fc0bbf7a _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt5Core.so.5 + 0xeef7a) #3 0x00007f01fc0b9774 _ZN17QThreadPoolThread3runEv (libQt5Core.so.5 + 0xec774) #4 0x00007f01fc0b64a6 _ZN14QThreadPrivate5startEPv (libQt5Core.so.5 + 0xe94a6) #5 0x00007f01fbe80299 start_thread (libpthread.so.0 + 0x9299) #6 0x00007f01fbaad353 __clone (libc.so.6 + 0x100353)
Operating System: Fedora 34 KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 Kernel Version: 5.14.9-200.fc34.x86_64 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-7500 CPU @ 3.40GHz Memory: 15,5 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630
Please show output of this command: `rpm -qf /usr/lib64/libkwin.so.5`.
rpm -qf /usr/lib64/libkwin.so.5 > kwin-libs-5.22.5-1.fc34.x86_64
Theory: you have some packages mixed from other repos (maybe `kwin-wayland`). Till that's looks to me as packaging issue let's move to https://github.com/ZaWertun/fedora-copr-kde5/issues.
i removed zawertun repos completely, and added dnf debuginfo-install kwin\* plasma\* Moreover, i attached a different monitor (old hdmi-to-dvi 1280x1024 screen) instead of the 4K monitor. So, even with the official repo kwin/plasma files, the wayland session crashes repeatedly
Created attachment 142222 [details] bt full
the monitor change was tested because of the following strange event: i have a 4K monitor connected via displayport, the same monitor is display for two machines, laptop and m910x. I just reproduced this very odd behaviour: When i connect the monitor to m910x machine, then try to log in, then i see the background, but no widgets, a short time later, the session crashes. So, to get to the coredump, i have a ssh session open to m910x - i switched the monitor to the laptop, while m910x was still in the try and crash loop. Then, after some wait, i connected the monitor back to m910x - and: surprisingly, the kwin desktop was here having also a menubar, with clock and some widgets in the panel of menubar, looking pretty much ok (not full ok, the pinned icons were missing, but it was too quick to tell details). But, one second into this, it crashes again and the desktop never comes up again in the following die-and-retry loop. Repeat the whole thing: monitor to m910x, log in, let it crash, disconnect monitor, wait, reconnect and - voila - menubar on the desktop. And crashing immediately after ~1 sec This was only seen with the 4K monitor, with the hdmi/dvi connected old monitor this did not happen. Here, i had something different: some popups were rendered on the desktop background in the lower left corner (still no menubar). One indicatint sth. about rpc bind and next time a familiar looking crash notificationi popup. Full with animation But, no details here, crash came too quickly So i think, the problem is more fundamental than just kwin/wayland/plasma crashing?
Yaroslav recommended to provide this info as well: $ grep LayoutList ~/.config/kxkbrc LayoutList=eu,us
(In reply to slartibart70 from comment #23) > Yaroslav recommended to provide this info as well: > > $ grep LayoutList ~/.config/kxkbrc > LayoutList=eu,us Considering the recent backtrace, XKB thinks there are 4 layouts, but you have only 2 in kxkbrc configured: #5 KWin::KeyboardLayoutDBusInterface::getLayoutsList (this=0x5626bc88c680) at /usr/src/debug/kwin-5.22.5-1.fc34.x86_64/src/keyboard_layout.cpp:234 i = 3 ... layoutsSize = 4 displayNamesSize = 2 Try to determine source of the extra layouts: (In reply to slartibart70 from comment #9) > Regarding keyboard: maybe just on slight thing that comes to my mind: i > added a remapping of caps-lock to control key in a separate mapping file > which is loaded / added with localctl > > Could this interfere somehow? Let's eliminate that. Make sure there is no external mapping taking place, no XKB.. environment variables with configuration, etc.
(In reply to Andrey from comment #24) > Try to determine source of the extra layouts: XKB_LOG_LEVEL, XKB_LOG_VERBOSITY environment variables might be helpful, see https://xkbcommon.org/doc/current/group__context.html
@slartibart70, please also run this command: `xkbcomp $DISPLAY ~/output.xkb`. And upload file `output.xkb` here.
(In reply to slartibart70 from comment #23) > Yaroslav recommended to provide this info as well: > > $ grep LayoutList ~/.config/kxkbrc > LayoutList=eu,us Please paste all the kxkbrc file
$ cat ~/.config/kxkbrc [$Version] update_info=kxkb_variants.upd:split-variants [Layout] DisplayNames=, LayoutList=eu,us LayoutLoopCount=-1 Model=pc101 Options=caps:ctrl_modifier,lv3:lsgt_switch,lv3:ralt_alt ResetOldOptions=true ShowFlag=false ShowLabel=true ShowLayoutIndicator=true ShowSingle=false SwitchMode=Global Use=true VariantList=, # additionally, my modified xkb map for vconsoles (same as above, Caps is Control) cat /etc/vconsole.conf KEYMAP=us-caps FONT=ter-122b $ diff --color <(zcat /usr/lib/kbd/keymaps/xkb/us.map.gz) <(zcat /usr/lib/kbd/keymaps/xkb/us-caps.map.gz) 16c16 < keycode 15 = Tab Meta_Tab Tab Meta_Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Meta_Tab Tab Meta_Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Meta_Tab Tab Meta_Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Meta_Tab Tab Meta_Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Meta_Tab Tab Meta_Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Meta_Tab Tab Meta_Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Meta_Tab Tab Meta_Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Meta_Tab Tab Meta_Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab --- > keycode 15 = Tab Tab Tab Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Tab Tab Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Tab Tab Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Tab Tab Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Tab Tab Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Tab Tab Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Tab Tab Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Tab Tab Tab Tab Tab Tab Tab Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab Meta_Tab 59c59 < keycode 58 = Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock Caps_Lock --- > keycode 58 = Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control
Created attachment 142238 [details] output.xkb
I see there is only 2 keyboard layouts in the `output.xkb`: 0. 'EurKEY (US)' 1. 'English (US)' (it corresponds to the info from the `~/.config/kxkbrc`).
i tried the following: - deactivat caps lock as control - deactivat 3rd level (never alt, <> key) so, basically a reset to default removed the eurKey layout, only us remains in the list no change to the vconsole layout (still us-caps) AND: Wayland does not crash, gui is working and usable (but, i *DO* like Ctrl on Caps, i use VI ... :-)
(In reply to slartibart70 from comment #31) > i tried the following: > - deactivat caps lock as control > - deactivat 3rd level (never alt, <> key) > so, basically a reset to default > > removed the eurKey layout, only us remains in the list > Try to revert this bit by bit and determine what configuration exactly caused the crash. > no change to the vconsole layout (still us-caps) > In my understanding, it shouldn't interfere in any way.
I was able to reproduce with your config. Let's find the problematic bits.
(In reply to slartibart70 from comment #28) > Options=caps:ctrl_modifier,lv3:lsgt_switch,lv3:ralt_alt It's lv3:ralt_alt option which problematic ("Right Alt never chooses 3rd level" in the list) - upon applying, it crashes the session immediately :) I don't see any logic in this, it looks like xkbcommon bug, I'll report upstream.
Created attachment 142240 [details] kwin_wayland.xkb Just dumped XKB config from KWin running on Wayland. When parsing this file with xkbcommon - it returns 4 keyboard layouts: 0. 'English (US)' 1. 'Russian' 2. '' 3. ''
(In reply to Yaroslav Sidlovsky from comment #35) > Created attachment 142240 [details] > kwin_wayland.xkb > > Just dumped XKB config from KWin running on Wayland. > When parsing this file with xkbcommon - it returns 4 keyboard layouts: > > 0. 'English (US)' > 1. 'Russian' > 2. '' > 3. '' How exactly did you dump/parse it, and what was in kxkbrc file? I can guess here is the relevant lines: key <RALT> { type= "TWO_LEVEL", symbols[Group1]= [ Alt_R, Meta_R ], symbols[Group2]= [ Alt_R, Meta_R ], symbols[Group3]= [ Alt_R, Meta_R ], symbols[Group4]= [ Alt_R, Meta_R ]
Created attachment 142245 [details] Source code of app to parse xkb-files Just unzip it and `cmake . && make -j`. xkb-file should be placed in `~/kwin.xkb` (path is hardcoded).
Created attachment 142246 [details] My ~/.config/kxkbrc file
Here is the relevant part of /usr/share/X11/xkb/symbols/level3 which might be the reason: // The right Alt key never chooses the third level. // This option attempts to undo the effect of a layout's inclusion of // 'ralt_switch'. You may want to also select another level3 option // to map the level3 shift to some other key. partial modifier_keys xkb_symbols "ralt_alt" { key <RALT> { type[Group1]="TWO_LEVEL", type[Group2]="TWO_LEVEL", type[Group3]="TWO_LEVEL", type[Group4]="TWO_LEVEL", symbols[Group1] = [ Alt_R, Meta_R ], symbols[Group2] = [ Alt_R, Meta_R ], symbols[Group3] = [ Alt_R, Meta_R ], symbols[Group4] = [ Alt_R, Meta_R ] }; modifier_map Mod1 { <RALT> }; };
I opened upstream issue: https://github.com/xkbcommon/libxkbcommon/issues/262
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1508
Thanks for reporting, it's so unexpected we could never detect it ourselves.
Git commit 59143eeef9042f3c9996a06d21a5fe05dc870dcd by Andrey Butirsky. Committed on 12/10/2021 at 15:41. Pushed by butirsky into branch 'master'. [wayland] fix crash on startup with lv3:ralt_alt XKB option With lv3:ralt_alt ("Right Alt never chooses 3rd level") option set, we get more layouts from libxkbcommon than it was configured, see: https://github.com/xkbcommon/libxkbcommon/issues/262 It might be correct lib's behavior, still. The extra layouts are redundant, so we strip them out from usual usage. M +2 -2 src/xkb.cpp M +1 -1 src/xkb.h https://invent.kde.org/plasma/kwin/commit/59143eeef9042f3c9996a06d21a5fe05dc870dcd
Git commit ef6a9c47c5a77b45bdd77628279a4bfe85c97978 by Andrey Butirsky. Committed on 12/10/2021 at 15:43. Pushed by butirsky into branch 'Plasma/5.23'. [wayland] fix crash on startup with lv3:ralt_alt XKB option With lv3:ralt_alt ("Right Alt never chooses 3rd level") option set, we get more layouts from libxkbcommon than it was configured, see: https://github.com/xkbcommon/libxkbcommon/issues/262 It might be correct lib's behavior, still. The extra layouts are redundant, so we strip them out from usual usage. (cherry picked from commit 59143eeef9042f3c9996a06d21a5fe05dc870dcd) M +2 -2 src/xkb.cpp M +1 -1 src/xkb.h https://invent.kde.org/plasma/kwin/commit/ef6a9c47c5a77b45bdd77628279a4bfe85c97978
Please note the lv3:ralt_alt ("Right Alt never chooses 3rd level") option is still problematic on Wayland: https://invent.kde.org/plasma/kwin/-/merge_requests/1508#note_320276
(In reply to Andrey from comment #45) > Please note the lv3:ralt_alt ("Right Alt never chooses 3rd level") option is > still problematic on Wayland: > https://invent.kde.org/plasma/kwin/-/merge_requests/1508#note_320276 This has been confirmed as xkbcommon bug: https://github.com/xkbcommon/libxkbcommon/issues/262
Should have been fixed upstream: https://github.com/freedesktop/xkeyboard-config/commit/29f2cd1eecc540480fcaf4580bcdd78283734e31