When opening any new window (application, dialog, menu, etc) the window will often never appear and remains in an invisible state. Its process does however exist and is fully responsive. KWin seems to think it's there too, however Plasma doesn't show it in the task manager and alt-tab switching selects something non-existent... for example the drawing and selection order of windows completely breaks when an unrendered dialog is present. If attempting to switch desktops during this time, the session will crash and you're taken back to the login screen: Only way to "disarm" such crashes is to kill the process behind such a window (eg: from KSysGuard)... attempting to open the application again will usually work, though it may take several tries before the window will spawn properly. This issue renders the Plasma Wayland session next to unusable and requires constant user attention to work around hidden windows. I tried several things which don't seem to prevent the problem: First was a suggestion to boot with the amdgpu.dc=0 parameter which did not affect the issue. I attempted different combinations under System Settings - Hardware - Display and Monitor - Compositor, the scale method / render backend (OpenGL 2.0 or 3.1) / vsync didn't affect it either. I also played with some parameters under the Compositing section of ~/.config/kwinrc but couldn't find proper documentation on what each one does and what in there might help. Linux openSUSE Tumbleweed x64. Plasma 5.18.4. Mesa 20.0.4. Wayland 1.18 / 1.20. KWayland 5.68. AMD Radeon (TM) R9 390 Series (HAWAII, DRM 3.36.0, 5.6.2-1-default, LLVM 10.0.0). KWin theme is Aurorae, themes in use include: https://www.pling.com/p/1002663 https://www.pling.com/p/998653
Created attachment 127515 [details] kwinrc
I reported this to the Freedesktop team as well, they closed the ticket and mentioned it's not related to the Wayland protocol. This is likely a KWin exclusive bug or tied to a setting in the Plasma desktop, which is responsible for drawing the windows in the end. The crash itself is identical to what happens if you manually kill the kwin_wayland process... most likely that's the process being brought down by the broken windows.
Following a suggestion on the openSUSE bug tracker: I switched to the default Breeze KWin theme followed by logging out and back in. No change, issue still occurred. Attempting to start a test session with "LIBGL_ALWAYS_SOFTWARE=1 dbus-launch-session startplasmacompositor" wasn't possible as dbus-launch-session was reported as an unrecognized command when I looked at it. However I could solve this by adding "export LIBGL_ALWAYS_SOFTWARE=1" to ~/.profile then starting a new session normally: I can tell it worked since all desktop effects were disabled and the mouse cursor was extremely laggy (everything felt like it ran at 5 FPS). To my surprise even this didn't affect the issue, both the missing windows and session crash could still be reproduced after a number of attempts.
Crosslinking the downstream report: https://bugzilla.opensuse.org/show_bug.cgi?id=1169304
Might be the same as bug 398220 and 394803.
Created attachment 127542 [details] dbus-run-session startplasma-wayland --xwayland --x11-display $DISPLAY --exit-with-session=/usr/lib64/libexec/startplasma-waylandsession Thanks again Fabian Vogt from the openSUSE tracker for the new suggestions. Sharing the tests and results here too once more. Regarding whether this affects just Wayland or X11 clients: I don't know how to check which is which. However the issue does affect both Qt and GTK applications, KDE components or otherwise; So far I've seen it happen to KWrite, Konsole, KSysGuard, Firefox, Thunderbird, Audacious, etc. Since the first are default KDE components I'm assuming they're ran as native WL clients? In a console I set "export WAYLAND_DEBUG=1" followed by repeatedly launching and closing "kwrite". When eventually it opened with a hidden window, nothing was printed to this console. I killed the process and it only said "Terminated". I took a backup of ~/.config/plasma-org.kde.plasma.desktop-appletsrc to save my widget config, then successfully managed to use "dbus-run-session startplasma-wayland --xwayland --x11-display $DISPLAY --exit-with-session=/usr/lib64/libexec/startplasma-waylandsession" and start another session in a smaller window from within my normal session... I also set "export WAYLAND_DEBUG=1" in the console that spawned this debug session. I could reproduce the crash in this controlled environment too! Here's the output that was produced in the console running the nested session as that session collapsed.
(In reply to Mircea Kitsune from comment #6) > Created attachment 127542 [details] > dbus-run-session startplasma-wayland --xwayland --x11-display $DISPLAY > --exit-with-session=/usr/lib64/libexec/startplasma-waylandsession > > Thanks again Fabian Vogt from the openSUSE tracker for the new suggestions. > Sharing the tests and results here too once more. > > Regarding whether this affects just Wayland or X11 clients: I don't know how > to check which is which. However the issue does affect both Qt and GTK > applications, KDE components or otherwise; So far I've seen it happen to > KWrite, Konsole, KSysGuard, Firefox, Thunderbird, Audacious, etc. Since the > first are default KDE components I'm assuming they're ran as native WL > clients? Not necessarily, that depends on the environment. > In a console I set "export WAYLAND_DEBUG=1" followed by repeatedly launching > and closing "kwrite". When eventually it opened with a hidden window, > nothing was printed to this console. I killed the process and it only said > "Terminated". Ok, so that was using Xwayland then. You can set QT_QPA_PLATFORM=wayland / GDK_BACKEND=wayland to force wayland. > I took a backup of ~/.config/plasma-org.kde.plasma.desktop-appletsrc to save > my widget config, then successfully managed to use "dbus-run-session > startplasma-wayland --xwayland --x11-display $DISPLAY > --exit-with-session=/usr/lib64/libexec/startplasma-waylandsession" and start > another session in a smaller window from within my normal session... I also > set "export WAYLAND_DEBUG=1" in the console that spawned this debug session. > I could reproduce the crash in this controlled environment too! Here's the > output that was produced in the console running the nested session as that > session collapsed. Great! Can you run the command with "gdb --args" and collect a backtrace of the crash? (You'll have to "dbus-run-session gdb --args startplasma-wayland ...")
>however Plasma doesn't show it in the task manage So you do get the panels?
(In reply to Fabian Vogt from comment #7) Strange. I installed the needed devel package, ran the command with "dbus-run-session gdb --args ...", issued the "run" command to gdb, then reproduced the crash in the nested session. After the session crashed and closed, gdb didn't notice an actual crash: Telling it "bt" or "backtrace" reported "No stack". I assume I'm missing something in how I'm using gdb?
(In reply to David Edmundson from comment #8) What that comment referred to is the entry in the task manager on the default panel... in my case the Icon-Only Task Manager widget; Apart from the window itself not popping up, the icon of the window is not added to the bar either. To me this indicates it's not just an issue with rendering the window, causing it to appear invisible while all else works... the window is not properly spawned and detected by the system to some extent. The missing taskbar icon is present for every missing window, including the recent nested session tests.
Created attachment 127549 [details] corruption It appears that on rare occasions, some of these windows will end up causing graphical corruption and leaving weird trails behind. I noticed something like this before but didn't make a connection until now. Just caught a lucky break and managed to take a screenshot, posting in case it helps offer a pointer.
(In reply to Mircea Kitsune from comment #9) > (In reply to Fabian Vogt from comment #7) > > Strange. I installed the needed devel package, ran the command with > "dbus-run-session gdb --args ...", issued the "run" command to gdb, then > reproduced the crash in the nested session. After the session crashed and > closed, gdb didn't notice an actual crash: Telling it "bt" or "backtrace" > reported "No stack". I assume I'm missing something in how I'm using gdb? That would mean it didn't actually crash. Can you copy the full output here?
Created attachment 127563 [details] dbus-run-session gdb --args startplasma-wayland --xwayland --x11-display $DISPLAY --exit-with-session=/usr/lib64/libexec/startplasma-waylandsession > ./output 2>&1 Here's the output of the gdb session directed to a file as: dbus-run-session gdb --args startplasma-wayland --xwayland --x11-display $DISPLAY --exit-with-session=/usr/lib64/libexec/startplasma-waylandsession > ./output 2>&1 I'm also glad to announce I've apparently discovered an essential piece of the puzzle, just tested this heavily and will continue to do so. It appears this glitch only occurs when minimized windows are present in the session; If there are either no other windows or the existing windows are all maximized or restored, opening a new application seems to work just fine. This further caught my attention as some existing windows also rarely freeze (still rendered but visually unchanged) until I minimize and restore them... one of the similar bug reports additionally stated that minimizing and restoring hidden windows with a shortcut might recover them (I don't have this shortcut to test).
Oh, my fault: To debug kwin_wayland itself, you have to use dbus-run-session gdb --args kwin_wayland --xwayland --x11-display $DISPLAY --exit-with-session=/usr/lib64/libexec/startplasma-waylandsession
It appears I found a workaround and potentially the culprit, more testing required but it seems pretty certain so far. System Settings - Hardware - Display and Monitor - Compositor: "Keep window thumbnails" has to be set to "Always", the options "Never" or "Only for Shown Windows" are introducing this glitch. Although taskbar thumbnails still don't show up when hovering over an icon, I've been able to minimize and play around with opening / closing windows without getting the invisible windows and associated crashes any more. This also seems to fix another crash I thought was unrelated: When reordering applications on the taskbar (icon-only task manager widget) by click-dragging them, a crash would also occur for some applications. I'm reordering those applications now and no longer seem to be getting a session lock.
Created attachment 127564 [details] dbus-run-session gdb --args kwin_wayland --xwayland --x11-display $DISPLAY --exit-with-session=/usr/lib64/libexec/startplasma-waylandsession > ./output 2>&1 There we go... here's output of: dbus-run-session gdb --args kwin_wayland --xwayland --x11-display $DISPLAY --exit-with-session=/usr/lib64/libexec/startplasma-waylandsession > ./output 2>&1
Backtrace: Thread 1 "kwin_wayland" received signal SIGSEGV, Segmentation fault. 0x00007f84d1d85920 in KWayland::Server::SurfaceInterface::d_func() const () from /usr/lib64/libKF5WaylandServer.so.5 (gdb) bt #0 0x00007f84d1d85920 in KWayland::Server::SurfaceInterface::d_func() const () at /usr/lib64/libKF5WaylandServer.so.5 #1 0x00007f84d1d85a59 in KWayland::Server::SurfaceInterface::inhibitsIdle() const () at /usr/lib64/libKF5WaylandServer.so.5 #2 0x00007f84d217bcd9 in () at /usr/lib64/libkwin.so.5 #3 0x00007f84d20bca82 in KWin::Workspace::forEachAbstractClient(std::function<void (KWin::AbstractClient*)>) () at /usr/lib64/libkwin.so.5 #4 0x00007f84d217bc09 in () at /usr/lib64/libkwin.so.5 #5 0x00007f84d12319fe in () at /usr/lib64/libQt5Core.so.5 #6 0x00007f84d21e5e6d in KWin::Workspace::currentDesktopChanged(int, KWin::AbstractClient*) () at /usr/lib64/libkwin.so.5 #7 0x00007f84d20c3e13 in KWin::Workspace::slotCurrentDesktopChanged(unsigned int, unsigned int) () at /usr/lib64/libkwin.so.5 #8 0x00007f84d1231a30 in () at /usr/lib64/libQt5Core.so.5 #9 0x00007f84d21e63bf in KWin::VirtualDesktopManager::currentChanged(unsigned int, unsigned int) () at /usr/lib64/libkwin.so.5 #10 0x00007f84d20cfc34 in KWin::VirtualDesktopManager::setCurrent(KWin::VirtualDesktop*) () at /usr/lib64/libkwin.so.5 #11 0x00007f84d12319fe in () at /usr/lib64/libQt5Core.so.5 #12 0x00007f84cdc253ed in () at /usr/lib64/libffi.so.8 #13 0x00007f84cdc2134a in () at /usr/lib64/libffi.so.8 #14 0x00007f84ceee8df6 in () at /usr/lib64/libwayland-server.so.0 #15 0x00007f84ceeeea76 in () at /usr/lib64/libwayland-server.so.0 #16 0x00007f84ceeeb672 in wl_event_loop_dispatch () at /usr/lib64/libwayland-server.so.0 #17 0x00007f84d1dbac1f in KWayland::Server::Display::Private::dispatch() () at /usr/lib64/libKF5WaylandServer.so.5 #18 0x00007f84d12319fe in () at /usr/lib64/libQt5Core.so.5 #19 0x00007f84d1235131 in QSocketNotifier::activated(int, QSocketNotifier::QPrivateSignal) () at /usr/lib64/libQt5Core.so.5 #20 0x00007f84d1235471 in QSocketNotifier::event(QEvent*) () at /usr/lib64/libQt5Core.so.5 #21 0x00007f84d1642caf in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5 #22 0x00007f84d164bdf0 in QApplication::notify(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5 #23 0x00007f84d11fd002 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib64/libQt5Core.so.5 #24 0x00007f84d1250efb in QEventDispatcherUNIXPrivate::activateSocketNotifiers() () at /usr/lib64/libQt5Core.so.5 #25 0x00007f84d125134b in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #26 0x00007f84cb2665ed in () at /usr/lib64/qt5/plugins/platforms/KWinQpaPlugin.so #27 0x00007f84d11fbb9b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #28 0x00007f84d1203972 in QCoreApplication::exec() () at /usr/lib64/libQt5Core.so.5 #29 0x000055cf4ed1e562 in () #30 0x00007f84d0bafceb in __libc_start_main () at /lib64/libc.so.6 #31 0x000055cf4ed1e8ba in _start () That looks like bug 413295. A comment there references the virtual desktop OSD, do you have that enabled?
That trace shows we have a client that's reporting as visible yet has no surface from xwayland supplied. Arguably we could fix idleinhibition to have a guard, it doesn't really need to check xwayland clients, but this might be a symptom of your earlier problem rather than a bug in itself.
Created attachment 127565 [details] dbus-run-session gdb --args kwin_wayland --xwayland --x11-display $DISPLAY --exit-with-session=/usr/lib64/libexec/startplasma-waylandsession > ./output 2>&1 (debuginfo) Ooops: Forgot to install kwin5-debuginfo for the extra data. Here's everything with that package in place.
(In reply to Fabian Vogt from comment #17) > That looks like bug 413295. A comment there references the virtual desktop OSD, do you have that enabled? How do I check? If that refers to virtualization, I do have VirtualBox installed but I'm not running my session on it or having it active in any other way. If you mean the desktop switching widget, that is on my panel (2 desktops configured).
(In reply to Mircea Kitsune from comment #20) > (In reply to Fabian Vogt from comment #17) > > > That looks like bug 413295. A comment there references the virtual desktop OSD, do you have that enabled? > > How do I check? If that refers to virtualization, I do have VirtualBox > installed but I'm not running my session on it or having it active in any > other way. If you mean the desktop switching widget, that is on my panel (2 > desktops configured). It refers to those virtual desktops, yes. It's the "Workspace Behaviour" -> "Virtual Desktops" -> "Show on-screen display when switching". I think it's off by default though.
(In reply to Fabian Vogt from comment #21) > "Virtual Desktops" -> "Show on-screen display when switching" Yes, I see that checkbox but it's disabled for me, so that wouldn't be it.
All needed info got provided, setting to CONFIRMED as there are multiple reports about similar issues (though not confirmed to have the same cause)
Thank you, really appreciated the help. I'll keep "keep window thumbnails" at "always" in the meantime, it makes no difference anyway so I'm perfectly fine with it. When this is updated with a fix and openSUSE Tumbleweed can include it, I can give it a try and see how the behavior changes.
Git commit d0875aa11707dd042e14f8723e1fd141452dca80 by David Edmundson. Committed on 15/04/2020 at 23:57. Pushed by davidedmundson into branch 'Plasma/5.18'. [wayland] avoid potential crash when checking for window inhibitions on desktop change Summary: Xwayland clients are sometimes offset from being visible to having a surface applied. We might also have internal windows which will be AbstractClients without a surface. No idle interface will be set up for non wayland clients, but on a desktop change we itterate through all AbstractClients and need to guard somewhere. Test Plan: None Reviewers: #kwin, apol Reviewed By: apol Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D28858 M +1 -1 idle_inhibition.cpp https://commits.kde.org/kwin/d0875aa11707dd042e14f8723e1fd141452dca80
(In reply to David Edmundson from comment #25) Does this also fix the invisible windows? The session crash appears as more of a side effect to that... the core problem seems to be the renderer not "finding" a window when it's been minimized and deactivated. If not perhaps this should stay open until that part can be solved as well.
It will only fix the crash.
*** Bug 413295 has been marked as a duplicate of this bug. ***
Sorry, reading the description it's not instantly clear if it's XWayland problem or native Wayland clients are suffer also. If it's known already, could we please point it out in the Bug header? Probably "XWayland" flag would be useful also..
(In reply to Andrey from comment #29) > Sorry, reading the description it's not instantly clear if it's XWayland > problem or native Wayland clients are suffer also. > If it's known already, could we please point it out in the Bug header? > Probably "XWayland" flag would be useful also.. From my experience, this only affects XWayland windows. Another detail: I don't know if this has been mentioned before, but it seems that invisible windows do not receive some input events which normal windows do. For example, I often get invisible windows when opening the 'Open File' dialog in Kate. Visible dialogs can be closed with the 'Esc' key, but invisible ones cannot: I need to press Alt+F4 instead.
Thanks. I set it to Confirmed assuming the crash was fixed already, and it was reported multiple times.
(In reply to Mircea Kitsune from comment #15) > It appears I found a workaround and potentially the culprit, more testing > required but it seems pretty certain so far. System Settings - Hardware - > Display and Monitor - Compositor: "Keep window thumbnails" has to be set to > "Always", the options "Never" or "Only for Shown Windows" are introducing > this glitch. Although taskbar thumbnails still don't show up when hovering > over an icon, I've been able to minimize and play around with opening / > closing windows without getting the invisible windows and associated crashes > any more. I don't know if it's useful, but I wanted to throw a "me too" on this problem and solution using Xwayland. Was having this problem yesterday on opensuse tumbleweed with the windows being apparently invisible (though input fields, focus, buttons, etc, would still be "there"), though my session never crashed as a result of this behavior. Setting that compositor setting to "always" has stopped the behavior in its entirety.
Does this still happen with current versions?
*** Bug 398220 has been marked as a duplicate of this bug. ***
Can't reproduce FWIW.
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!
Going to assume this was fixed as I haven't seen it last time I tested Wayland, which was a while ago but WL changes a lot with each release: Most things discussed here are likely irrelevant after so many code rewrites and architecture changes. I'm on X11 due to WL still being unable to handle monitor power saving without something crashing every time; If and when that problem is someday finally resolved I'll switch for good and open new issues for any graphical glitches I may find.