#8  QMessageLogger::fatal (this=this@entry=0x7ffd81cbcf60, msg=msg@entry=0x7fd149e3a0f8 "The Wayland connection experienced a fatal error: %s") at /home/apol/devel/frameworks/qt5/qtbase/src/corelib/global/qlogging.cpp:893

> wl_display@1: error 0: invalid object 19
> The Wayland connection experienced a fatal error: Invalid argument

I believe the problem is that QtWayland tries to do something with an already destroyed xdg_output resource and libwayland doesn't like it.

We should probably **not** destroy xdg_output resources if the associated wl_output global has been removed. It would be nice if we could install some dummy wl_resource implementation that only implements the destructor request or maybe let qtwaylandscanner generated code handle inert resources.

Relevant: https://codereview.qt-project.org/c/qt/qtwayland/+/308984

@David what do you mean with that MR? Isn't it doing an exit anyway? The fact that it will not be crashing but still closing all clients is still as bad.

I misunderstood the report from the backtrace. Ignore me

I came here to say that this issue hits me too. I searched up this issue recently, but somehow missed this report or I'd have gotten involved sooner.

Docking my laptop works as expected, extra screens are added just fine. But as soon as I undock, all the Qt applications crash. The debugging I did arrived at the same conclusion as Vlad, but I don't have enough knowledge of wayland to help with this bug.

I'm using Gentoo live ebuilds for plasma, so I have not reported this issue due to this.

Happy to help in any way I can however.

Happens for me too. On sway the apps don't crash though.

Relevant merge request https://invent.kde.org/plasma/kwayland-server/-/merge_requests/98

Just to double check, MR!98 is for a version of Qt (5.15.3) that isn't even on the Qt release schedule yet?

I have the latest stable Qt release, QT 5.15.1 installed, and this patch is just a noop for that version. I tried changing the version check in your diff to 5.15.1, but kwin just crashes when removing a monitor.

I'm super keen to try out this diff, and I'm happy to upgrade to an unstable Qt to do so if required, but wanted to check.

Does that mean this bug could take a while to land a fix for since we'll be waiting for upstream Qt?

Thank you for your time looking in to this issue!

No, I screwed the pooch with Qt versions. It's 5.15.2

(In reply to Vlad Zahorodnii from comment #9)
> No, I screwed the pooch with Qt versions. It's 5.15.2

All good. I rebuilt the relevant parts of Qt 5.15.1 with your patches from qtwayland.

- https://code.qt.io/cgit/qt/qtwayland.git/commit/?id=c594b7622f52dea291d33757b74971b3902b5d37
- https://code.qt.io/cgit/qt/qtwayland.git/commit/?id=4a4c35a856cf64f0e165cc3cfaeb1a3bbbf471f6

Then applied your MR!98 - changing the version check to 5.15.1 and rebuilt kwayland-server and relevant plasma bits.

I am able to confirm that unplugging my dock no longer kills the Qt clients. I've tried a variety of screen configurations and adding/removing displays via my dock works perfectly.

Nice work! Thank you

Great, thank you for testing.

Git commit 3987c0aecfb2f7e9e1222a61a75ad32a0b592c08 by Vlad Zahorodnii.
Committed on 13/10/2020 at 05:58.
Pushed by vladz into branch 'master'.

Properly handle destruction of XdgOutputV1Interface

The xdg-output spec omits whether the compositor has to destroy all xdg-
output resources when the associated wl_output global is removed.

This means that no xdg-output resource should be destroyed unless the
client has called the destructor request; otherwise the client may panic
due to protocol errors.

Starting with Qt 5.15.2, it's okay to destroy generated wrapper objects
without destroying associated resources. Destructor requests will be
handled behind the scenes for inert and orphaned resources by code that
is generated by qtwaylandscanner.

M  +4    -1    src/server/xdgoutput_v1_interface.cpp

https://invent.kde.org/plasma/kwayland-server/commit/3987c0aecfb2f7e9e1222a61a75ad32a0b592c08

Git commit 7a8ac182d4ddcfbafe7badc89778ff5b6c375777 by Vlad Zahorodnii.
Committed on 13/10/2020 at 18:06.
Pushed by vladz into branch 'Plasma/5.20'.

Properly handle destruction of XdgOutputV1Interface

The xdg-output spec omits whether the compositor has to destroy all xdg-
output resources when the associated wl_output global is removed.

This means that no xdg-output resource should be destroyed unless the
client has called the destructor request; otherwise the client may panic
due to protocol errors.

Starting with Qt 5.15.2, it's okay to destroy generated wrapper objects
without destroying associated resources. Destructor requests will be
handled behind the scenes for inert and orphaned resources by code that
is generated by qtwaylandscanner.


(cherry picked from commit 3987c0aecfb2f7e9e1222a61a75ad32a0b592c08)

M  +4    -1    src/server/xdgoutput_v1_interface.cpp

https://invent.kde.org/plasma/kwayland-server/commit/7a8ac182d4ddcfbafe7badc89778ff5b6c375777

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

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

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

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

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

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

Created attachment 135954 [details]
New crash information added by DrKonqi

plasmashell (5.21.0) using Qt 5.15.2

- What I was doing when the application crashed:
turned   on   my TV  (monitor)

- Custom settings of the application:

Wayland enabled (full wayland)

-- Backtrace (Reduced):
#6  0x00007f61112770e7 in qt_message_fatal (message=<synthetic pointer>..., context=...) at global/qlogging.cpp:1914
#7  QMessageLogger::fatal (this=this@entry=0x7ffc3d6312e0, msg=msg@entry=0x7f610f5400f8 "The Wayland connection experienced a fatal error: %s") at global/qlogging.cpp:893
#8  0x00007f610f4c9df0 in QtWaylandClient::QWaylandDisplay::checkError (this=<optimized out>) at qwaylanddisplay.cpp:211
#9  0x00007f610f4cae0a in QtWaylandClient::QWaylandDisplay::flushRequests (this=0x55f70321a230) at qwaylanddisplay.cpp:222
#10 0x00007f61114c9980 in doActivate<false> (sender=0x55f703252630, signal_index=4, argv=0x7ffc3d6313f0, argv@entry=0x0) at kernel/qobject.cpp:3898

Created attachment 135956 [details]
New crash information added by DrKonqi

plasmashell (5.21.0) using Qt 5.15.2

Still happening on openSUSE Tumbleweed, Plasma 5.21.0 with QT 5.15.2

- What I was doing when the application crashed:
Turn my HDMI screen off and on again

- Custom settings of the application:
KDE wayland session

-- Backtrace (Reduced):
#6  0x00007fe9b46930e7 in qt_message_fatal (message=<synthetic pointer>..., context=...) at global/qlogging.cpp:1914
#7  QMessageLogger::fatal (this=this@entry=0x7ffc4ec07470, msg=msg@entry=0x7fe9b295c0f8 "The Wayland connection experienced a fatal error: %s") at global/qlogging.cpp:893
#8  0x00007fe9b28e5df0 in QtWaylandClient::QWaylandDisplay::checkError (this=<optimized out>) at qwaylanddisplay.cpp:211
#9  0x00007fe9b28e6e0a in QtWaylandClient::QWaylandDisplay::flushRequests (this=0x55c1bdb483f0) at qwaylanddisplay.cpp:222
#10 0x00007fe9b28eecff in QtWaylandClient::QWaylandWindow::setVisible (this=0x55c1c08d8020, visible=<optimized out>) at qwaylandwindow.cpp:430

Created attachment 135994 [details]
New crash information added by DrKonqi

plasmashell (5.21.0) using Qt 5.15.2

- What I was doing when the application crashed:
Turned off monitor (TV) and on again
- Custom settings of the application:
"Full Wayland" enabled

-- Backtrace (Reduced):
#6  0x00007f43665540e7 in qt_message_fatal (message=<synthetic pointer>..., context=...) at global/qlogging.cpp:1914
#7  QMessageLogger::fatal (this=this@entry=0x7ffd9457f120, msg=msg@entry=0x7f436481d0f8 "The Wayland connection experienced a fatal error: %s") at global/qlogging.cpp:893
#8  0x00007f43647a6df0 in QtWaylandClient::QWaylandDisplay::checkError (this=<optimized out>) at qwaylanddisplay.cpp:211
#9  0x00007f43647a7e0a in QtWaylandClient::QWaylandDisplay::flushRequests (this=0x55758f56a230) at qwaylanddisplay.cpp:222
#10 0x00007f43647afcff in QtWaylandClient::QWaylandWindow::setVisible (this=0x557593ab8620, visible=<optimized out>) at qwaylandwindow.cpp:430

Any news on this one here? I'm still experiencing these crashes

https://invent.kde.org/plasma/kwayland-server/-/merge_requests/156 should help with plasmashell crashing.

(In reply to Vlad Zahorodnii from comment #24)
> https://invent.kde.org/plasma/kwayland-server/-/merge_requests/156 should
> help with plasmashell crashing.

Thank you for the feedback. I'm looking forward to being able to test it :-)

With https://invent.kde.org/plasma/kwayland-server/-/commit/589e339da06da6237d19218baf6822ac0016220f being merged, Qt clients should stay alive when an output is disconnected. The fix will be available only in 5.22. If apps still crash, please reopen this bug report.

(In reply to Vlad Zahorodnii from comment #26)
> With
> https://invent.kde.org/plasma/kwayland-server/-/commit/
> 589e339da06da6237d19218baf6822ac0016220f being merged, Qt clients should
> stay alive when an output is disconnected. The fix will be available only in
> 5.22. If apps still crash, please reopen this bug report.

@Vlad

I have just tested with the latest kwin. While the issue has significantly improved, it is not fixed completely.

The applications do not crash any more. But most KDE applications (dolphin, konsole) which were already running while the HDMI display cable was unplugged, go into a frozen state consuming 100% CPU cycles. Those applications do not recover at all.

I'd really love to see this issue fixed before the final 5.22 release. So please, help me help you with whatever information you may need.

Operating System: Debian GNU/Linux 11
KDE Plasma Version: 5.21.90
KDE Frameworks Version: 5.82.0
Qt Version: 5.15.2
Kernel Version: 5.10.0-7-amd64 (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz
Memory: 15.4 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620

These are new symptoms, please open a new report for this

(In reply to Nicolas Fella from comment #28)
> These are new symptoms, please open a new report for this

Great. You want to let go of all the information and context that was reported with the bug report. And just because a claimed fix changed the reflection of the bug, you are calling it a fixed one.

I am not going to file another bug report. The devs asked to report bugs with the beta release and so I did. You can choose to self-proclaim that this issue is fixed.

We'll be happy to investigate and fix the new issue you're having, but you have to file a new bug report for it; using the same bug report for a new issue is even more confusing. You can also link your new bug report with this one using the "See also" field.

In 5.22 I don't get any crash reports after turning my screen off and on again, but plasmashell seems to quit completely. Is there already a bug report filed for this?

Not to my knowledge. Go ahead and file one.

Might be related to 420160, but I struggle to get some debug logs as Dr. Konqui hangs at the end of getting the backtrace and doesn't finish the process. This is reproduceable on all my machines.

Created attachment 141055 [details]
New crash information added by DrKonqi

kdeconnectd (20.12.3) using Qt 5.15.2

- What I was doing when the application crashed:

I have connected two external Displays over USB-C connections, when I unplug the connectors, the crash happens. The Desktop is using Wayland.

-- Backtrace (Reduced):
#4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#5  0x00007f96b9164864 in __GI_abort () at abort.c:79
#6  0x00007f96b95d5c77 in QMessageLogger::fatal(char const*, ...) const () from /lib/x86_64-linux-gnu/libQt5Core.so.5
[...]
#8  0x00007f96b5af6f9a in QtWaylandClient::QWaylandDisplay::flushRequests() () from /lib/x86_64-linux-gnu/libQt5WaylandClient.so.5
[...]
#10 0x00007f96b9838be3 in QSocketNotifier::activated(QSocketDescriptor, QSocketNotifier::Type, QSocketNotifier::QPrivateSignal) () from /lib/x86_64-linux-gnu/libQt5Core.so.5