Created attachment 172538 [details] Back and Stacktraces, KWin Support Information SUMMARY Now I know this might be somewhat extremely specific, but KWin both in X11 and on Wayland / XWayland crashes when trying to right click inside a Microsoft Office Window that is produced by Winflector, with Winflector being a RDP-like Solution that has a native Linux Client I am unsure if this is a KWin or a Winflector Issue, but im reporting it here first as the Crash happens in KWin STEPS TO REPRODUCE 1. Get a VM that has Microsoft Office and Winflector Installed, with Winflector configured to share Microsoft Word 2. Start the Winflector Client on the Host, connect to the VM and launch Word 3. Make a blank new Document and start typing something 4. Try to open a context-menu on your typed text or try to get a tooltip on the formatting buttons to show OBSERVED RESULT Crashes the entire Wayland Session and all open Programs, Restarts KWin on X11 with Programs staying open EXPECTED RESULT The context menu appears without crashing KWin SOFTWARE/OS VERSIONS Linux/KDE Plasma: EndeavourOS, 6.10.3-arch1-2 KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION Winflector: https://www.winflector.com/ Microsoft Office used was Version 2407, Build 17830.20138, Current Channel Office and the Winflector Client are both running in a KVM VM on the Host, with the Winflector Client on the Host connecting to the VM using a local IP
#2 0x00007d2ff344c120 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26 #3 0x00007d2ff6d1f643 in KCrash::defaultCrashHandler (sig=11) at /usr/src/debug/kcrash/kcrash-6.4.0/src/kcrash.cpp:597 #4 0x00007d2ff344c1d0 in <signal handler called> () at /usr/lib/libc.so.6 #5 0x00007d2ff3b4d43a in QMetaObject::cast (this=0x7d2ff6b30180 <KWin::X11Window::staticMetaObject>, obj=obj@entry=0x1e) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qmetaobject.cpp:395 #6 0x00007d2ff664532b in qobject_cast<KWin::X11Window const*> (object=0x1e) at /usr/include/qt6/QtCore/qobject.h:423 #7 KWin::computeLayer (window=0x1e) at /usr/src/debug/kwin/kwin-6.1.4/src/layers.cpp:535 #8 KWin::Workspace::constrainedStackingOrder (this=this@entry=0x5848101ba660) at /usr/src/debug/kwin/kwin-6.1.4/src/layers.cpp:551 #9 0x00007d2ff6646595 in KWin::Workspace::updateStackingOrder (this=0x5848101ba660, propagate_new_windows=false) at /usr/src/debug/kwin/kwin-6.1.4/src/layers.cpp:103 #10 KWin::Workspace::updateStackingOrder (this=this@entry=0x5848101ba660, propagate_new_windows=propagate_new_windows@entry=false) at /usr/src/debug/kwin/kwin-6.1.4/src/layers.cpp:95 #11 0x00007d2ff6646811 in KWin::Workspace::restack (this=0x5848101ba660, window=0x584811925d00, under=<optimized out>, force=<optimized out>) at /usr/src/debug/kwin/kwin-6.1.4/src/layers.cpp:472 #12 0x00007d2ff67d7b3a in KWin::X11Window::restackWindow (this=0x584811925d00, above=<optimized out>, detail=<optimized out>, src=<optimized out>, timestamp=3023038, send_event=false) at /usr/src/debug/kwin/kwin-6.1.4/src/x11window.cpp:5525 #13 0x00007d2ff67ae5a9 in KWin::X11Window::configureRequestEvent (this=0x584811925d00, e=0x7d2fe0017a80) at /usr/src/debug/kwin/kwin-6.1.4/src/events.cpp:734 #14 KWin::X11Window::configureRequestEvent (this=0x584811925d00, e=0x7d2fe0017a80) at /usr/src/debug/kwin/kwin-6.1.4/src/events.cpp:705 #15 0x00007d2ff67b03dc in KWin::X11Window::windowEvent (this=0x584811925d00, e=0x7d2fe0017a80) at /usr/src/debug/kwin/kwin-6.1.4/src/events.cpp:463 #16 0x00007d2ff67aafad in KWin::Workspace::workspaceEvent (this=0x5848101ba660, e=0x7d2fe0017a80) at /usr/src/debug/kwin/kwin-6.1.4/src/events.cpp:156 #17 0x00007d2ff3b41bbf in QAbstractEventDispatcher::filterNativeEvent (this=<optimized out>, eventType=..., message=message@entry=0x7d2fe0017a80, result=result@entry=0x7ffd4a2c67e0) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qabstracteventdispatcher.cpp:432
The crash is interesting to us, but the setup to reproduce is quite difficult. Can you help get some more information for us, can you get setup and then run 'valgrind kwin_x11 --replace' . Things will be super slow, it's doing some intense tracking. Then reproduce the right clicking issue and share the output.
Created attachment 172646 [details] Valgrind Output
(In reply to David Edmundson from comment #2) > The crash is interesting to us, but the setup to reproduce is quite > difficult. > > Can you help get some more information for us, can you get setup and then run > 'valgrind kwin_x11 --replace' . Things will be super slow, it's doing some > intense tracking. > > Then reproduce the right clicking issue and share the output. I ran 'valgrind kwin_x11 --replace' and have added it's console output as an Attachment, valgrind also made a 1.2 GB 'vgcore.3624' file although im unsure if it's useful or how I am going to upload it
Thanks. The vgcore isn't too useful you can delete that.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6268
@Peter Does the crash happen consistently? Do you know if it's reproducible with any other app? or is it possible to prepare a VM image with everything included so we could debug the crash? As David said, the reproduction steps are difficult
(In reply to Vlad Zahorodnii from comment #7) > @Peter Does the crash happen consistently? Do you know if it's reproducible > with any other app? or is it possible to prepare a VM image with everything > included so we could debug the crash? As David said, the reproduction steps > are difficult So far this happens pretty consistently with Office Applications, I have tried other Applications like 7-Zip, AIDA64, MPC-HC, built-in Windows Apps/Tools, Microsoft Edge, and none of them have this behavior I can prepare a VM Image
> I can prepare a VM Image Thank you! If you don't want to share it in public, feel free to send an email either to David or me. You can the corresponding email addresses by clicking names in bugzilla.
You can find*
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6276
Git commit d028e3b1e9fec3b09fffa02208378acd4e37c7ae by Vlad Zahorodnii. Committed on 20/08/2024 at 12:09. Pushed by vladz into branch 'master'. Make Workspace::removeUnmanaged() keep the window in the stack It's leftover after the Deleted type. The unmanaged window will be removed from the stack when all its references are dropped and Workspace::removeDeleted() is called. M +0 -2 src/workspace.cpp https://invent.kde.org/plasma/kwin/-/commit/d028e3b1e9fec3b09fffa02208378acd4e37c7ae
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6283
Git commit 1b60415c2081610824660d65578af59ceaad0b8a by Vlad Zahorodnii. Committed on 20/08/2024 at 12:19. Pushed by vladz into branch 'Plasma/6.1'. Make Workspace::removeUnmanaged() keep the window in the stack It's leftover after the Deleted type. The unmanaged window will be removed from the stack when all its references are dropped and Workspace::removeDeleted() is called. (cherry picked from commit d028e3b1e9fec3b09fffa02208378acd4e37c7ae) Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org> M +0 -2 src/workspace.cpp https://invent.kde.org/plasma/kwin/-/commit/1b60415c2081610824660d65578af59ceaad0b8a
Git commit 9c611ddaea17ff13f328f509dad5f3a5f75e8fbf by Vlad Zahorodnii. Committed on 20/08/2024 at 12:27. Pushed by vladz into branch 'master'. Fix a crash in computeLayer() On X11, the stack order of a window can be changed in multiple ways: - Opposite - TopIf - BottomIf - Above - Below You would pass either of those modes plus maybe the above window id. For this crash, the relevant mode is Above. Since the Workspace only has one restack function that places the given window right under the reference window, the Above stack mode implementation performs a quirk: it walks through the stack in order to find a window right above the reference window and pass it to the restack() function. However, it could be that the window that wants to be restacked is already above the reference window, so that same window would be passed as the "under" window to the restack() function. It's nothing but a miracle that we have not received major complaints about this issue until now. The restack() function doesn't like `window` and `under` to be the same because of code like unconstrained_stacking_order.removeAll(window); unconstrained_stacking_order.insert(unconstrained_stacking_order.indexOf(under), window); The removeAll() function would effectively remove both `window` and `under` from the unconstrained stack, which breaks the next line because the indexOf() would return -1, i.e. unconstrained_stacking_order.insert(-1, window); This is the reason why the unconstrained_stacking_order contains strange values such as `0xe`. In order to fix the crash, this change adds some code to short-circuit the restack() function if the passed in window and the reference window are the same. It would be great to clean up X11Window::restackWindow() and also add ergonomic restack functions in the Workspace, but this can be done later. The major blocker is lack of proper test coverage of X11 bits at the moment. Last but not least, I would like to express my profound gratitude to Peter Strick for filing the crash report AND providing a VM image that helped massively with reproducing the crash and finally fixing it. M +8 -6 src/layers.cpp https://invent.kde.org/plasma/kwin/-/commit/9c611ddaea17ff13f328f509dad5f3a5f75e8fbf
Git commit 758f6dad7e68058c6ba0a1d3727f78223b23826f by Vlad Zahorodnii. Committed on 20/08/2024 at 12:42. Pushed by vladz into branch 'Plasma/6.1'. Fix a crash in computeLayer() On X11, the stack order of a window can be changed in multiple ways: - Opposite - TopIf - BottomIf - Above - Below You would pass either of those modes plus maybe the above window id. For this crash, the relevant mode is Above. Since the Workspace only has one restack function that places the given window right under the reference window, the Above stack mode implementation performs a quirk: it walks through the stack in order to find a window right above the reference window and pass it to the restack() function. However, it could be that the window that wants to be restacked is already above the reference window, so that same window would be passed as the "under" window to the restack() function. It's nothing but a miracle that we have not received major complaints about this issue until now. The restack() function doesn't like `window` and `under` to be the same because of code like unconstrained_stacking_order.removeAll(window); unconstrained_stacking_order.insert(unconstrained_stacking_order.indexOf(under), window); The removeAll() function would effectively remove both `window` and `under` from the unconstrained stack, which breaks the next line because the indexOf() would return -1, i.e. unconstrained_stacking_order.insert(-1, window); This is the reason why the unconstrained_stacking_order contains strange values such as `0xe`. In order to fix the crash, this change adds some code to short-circuit the restack() function if the passed in window and the reference window are the same. It would be great to clean up X11Window::restackWindow() and also add ergonomic restack functions in the Workspace, but this can be done later. The major blocker is lack of proper test coverage of X11 bits at the moment. Last but not least, I would like to express my profound gratitude to Peter Strick for filing the crash report AND providing a VM image that helped massively with reproducing the crash and finally fixing it. (cherry picked from commit 9c611ddaea17ff13f328f509dad5f3a5f75e8fbf) Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org> M +8 -6 src/layers.cpp https://invent.kde.org/plasma/kwin/-/commit/758f6dad7e68058c6ba0a1d3727f78223b23826f