Bug 491618

#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

*** Bug 496588 has been marked as a duplicate of this bug. ***