Bug 426293

Summary: All my Qt clients die when I disconnect my display
Product: [Plasma] kwin Reporter: Aleix Pol <aleixpol>
Component: wayland-genericAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: alexander.reimelt, bugseforuns, chris-hartmann, ilgaz, kde-bugs, kde, lewis, nate, nicolas.fella, sven.guenther, torotil
Priority: NOR    
Version: git master   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In: 5.22
Sentry Crash Report:
Attachments: New crash information added by DrKonqi
New crash information added by DrKonqi
New crash information added by DrKonqi
New crash information added by DrKonqi

Description Aleix Pol 2020-09-07 22:20:16 UTC
Might be a bug in QtWayland/client, used to bring the whole session down, now it's just Qt clients. Firefox and XWayland clients survive it.

Here's a backtrace for kwrite, but I'm pretty sure all other QtGui processes crashed (I get like ~20 drkonqi SNI wanting attention).

Application: KWrite (kwrite), signal: Aborted
Content of s_kcrashErrorMessage: (null)
[New LWP 33411]
[New LWP 33412]
[New LWP 33413]
[New LWP 33414]
[New LWP 33415]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
0x00007fd14e36a46f in poll () from /usr/lib/libc.so.6
[Current thread is 1 (Thread 0x7fd14a3e7d40 (LWP 33408))]

Thread 6 (Thread 0x7fd13b159640 (LWP 33415)):
#0  0x00007fd14d73a6a2 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00007fd141d7290c in ?? () from /usr/lib/dri/iris_dri.so
#2  0x00007fd141d71308 in ?? () from /usr/lib/dri/iris_dri.so
#3  0x00007fd14d7343e9 in start_thread () from /usr/lib/libpthread.so.0
#4  0x00007fd14e375293 in clone () from /usr/lib/libc.so.6

Thread 5 (Thread 0x7fd133159640 (LWP 33414)):
#0  0x00007fd14d73a6a2 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00007fd141d7290c in ?? () from /usr/lib/dri/iris_dri.so
#2  0x00007fd141d71308 in ?? () from /usr/lib/dri/iris_dri.so
#3  0x00007fd14d7343e9 in start_thread () from /usr/lib/libpthread.so.0
#4  0x00007fd14e375293 in clone () from /usr/lib/libc.so.6

Thread 4 (Thread 0x7fd13b95a640 (LWP 33413)):
#0  0x00007fd14d73a6a2 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00007fd141d7290c in ?? () from /usr/lib/dri/iris_dri.so
#2  0x00007fd141d71308 in ?? () from /usr/lib/dri/iris_dri.so
#3  0x00007fd14d7343e9 in start_thread () from /usr/lib/libpthread.so.0
#4  0x00007fd14e375293 in clone () from /usr/lib/libc.so.6

Thread 3 (Thread 0x7fd13c15b640 (LWP 33412)):
#0  0x00007fd14d73a6a2 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00007fd141d7290c in ?? () from /usr/lib/dri/iris_dri.so
#2  0x00007fd141d71308 in ?? () from /usr/lib/dri/iris_dri.so
#3  0x00007fd14d7343e9 in start_thread () from /usr/lib/libpthread.so.0
#4  0x00007fd14e375293 in clone () from /usr/lib/libc.so.6

Thread 2 (Thread 0x7fd148dab640 (LWP 33411)):
#0  0x00007fd14e36a46f in poll () from /usr/lib/libc.so.6
#1  0x00007fd14af60168 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007fd14af11221 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007fd14eaafa9b in QEventDispatcherGlib::processEvents (this=0x7fd144000b60, flags=...) at /home/apol/devel/frameworks/qt5/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:425
#4  0x00007fd14ea56eeb in QEventLoop::exec (this=this@entry=0x7fd148daabf0, flags=..., flags@entry=...) at ../../include/QtCore/../../../../../devel/frameworks/qt5/qtbase/src/corelib/global/qflags.h:141
#5  0x00007fd14e877b8e in QThread::exec (this=<optimized out>) at ../../include/QtCore/../../../../../devel/frameworks/qt5/qtbase/src/corelib/global/qflags.h:121
#6  0x00007fd14ed48a27 in QDBusConnectionManager::run (this=0x7fd14edb5d80 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at /home/apol/devel/frameworks/qt5/qtbase/src/dbus/qdbusconnection.cpp:179
#7  0x00007fd14e878cd1 in QThreadPrivate::start (arg=0x7fd14edb5d80 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at /home/apol/devel/frameworks/qt5/qtbase/src/corelib/thread/qthread_unix.cpp:329
#8  0x00007fd14d7343e9 in start_thread () from /usr/lib/libpthread.so.0
#9  0x00007fd14e375293 in clone () from /usr/lib/libc.so.6

Thread 1 (Thread 0x7fd14a3e7d40 (LWP 33408)):
[KCrash Handler]
#5  0x00007fd14e2b2615 in raise () from /usr/lib/libc.so.6
#6  0x00007fd14e29b862 in abort () from /usr/lib/libc.so.6
#7  0x00007fd14e83dc41 in qt_message_fatal (message=<synthetic pointer>..., context=...) at /home/apol/devel/frameworks/qt5/qtbase/src/corelib/global/qlogging.cpp:1914
#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
#9  0x00007fd149dc3d80 in QtWaylandClient::QWaylandDisplay::checkError (this=<optimized out>) at /home/apol/build-devel/qt5/qtbase/include/QtCore/../../../../../devel/frameworks/qt5/qtbase/src/corelib/global/qlogging.h:90
#10 0x00007fd149dc3dce in QtWaylandClient::QWaylandDisplay::flushRequests (this=0x5609c7b87860) at /home/apol/devel/frameworks/qt5/qtwayland/src/client/qwaylanddisplay.cpp:222
#11 0x00007fd14ea8eb40 in doActivate<false> (sender=0x5609c7bc4170, signal_index=3, argv=argv@entry=0x7ffd81cbd0a0) at ../../include/QtCore/../../../../../devel/frameworks/qt5/qtbase/src/corelib/kernel/qobjectdefs_impl.h:395
#12 0x00007fd14ea87e60 in QMetaObject::activate (sender=sender@entry=0x5609c7bc4170, m=m@entry=0x7fd14ed28140 <QSocketNotifier::staticMetaObject>, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7ffd81cbd0a0) at /home/apol/devel/frameworks/qt5/qtbase/src/corelib/kernel/qobject.cpp:3946
#13 0x00007fd14ea91f3f in QSocketNotifier::activated (this=this@entry=0x5609c7bc4170, _t1=..., _t2=<optimized out>, _t3=...) at .moc/moc_qsocketnotifier.cpp:178
#14 0x00007fd14ea9273b in QSocketNotifier::event (this=0x5609c7bc4170, e=0x7ffd81cbd1b0) at /home/apol/devel/frameworks/qt5/qtbase/src/corelib/kernel/qsocketnotifier.cpp:302
#15 0x00007fd14f5e714f in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x5609c7bc4170, e=0x7ffd81cbd1b0) at /home/apol/devel/frameworks/qt5/qtbase/src/widgets/kernel/qapplication.cpp:3630
#16 0x00007fd14ea5852a in QCoreApplication::notifyInternal2 (receiver=0x5609c7bc4170, event=0x7ffd81cbd1b0) at ../../include/QtCore/5.15.1/QtCore/private/../../../../../../../../devel/frameworks/qt5/qtbase/src/corelib/thread/qthread_p.h:325
#17 0x00007fd14eab0635 in socketNotifierSourceDispatch (source=0x5609c7bc6c80) at /home/apol/devel/frameworks/qt5/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:107
#18 0x00007fd14af1243c in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#19 0x00007fd14af601d9 in ?? () from /usr/lib/libglib-2.0.so.0
#20 0x00007fd14af11221 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#21 0x00007fd14eaafa7f in QEventDispatcherGlib::processEvents (this=0x5609c7bc4a90, flags=...) at /home/apol/devel/frameworks/qt5/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:423
#22 0x00007fd14ea56eeb in QEventLoop::exec (this=this@entry=0x7ffd81cbd3c0, flags=..., flags@entry=...) at ../../include/QtCore/../../../../../devel/frameworks/qt5/qtbase/src/corelib/global/qflags.h:141
#23 0x00007fd14ea5f160 in QCoreApplication::exec () at ../../include/QtCore/../../../../../devel/frameworks/qt5/qtbase/src/corelib/global/qflags.h:121
#24 0x00005609c6416fe6 in main (argc=1, argv=0x7ffd81cbd668) at /home/apol/devel/frameworks/kate/kwrite/main.cpp:329
[Inferior 1 (process 33408) detached]
Comment 1 Vlad Zahorodnii 2020-09-08 06:23:04 UTC
#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.
Comment 2 David Edmundson 2020-09-08 08:59:20 UTC
Relevant: https://codereview.qt-project.org/c/qt/qtwayland/+/308984
Comment 3 Aleix Pol 2020-09-08 09:33:34 UTC
@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.
Comment 4 David Edmundson 2020-09-08 09:40:56 UTC
I misunderstood the report from the backtrace. Ignore me
Comment 5 Lewis Lakerink 2020-10-09 07:39:35 UTC
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.
Comment 6 Nicolas Fella 2020-10-12 18:27:39 UTC
Happens for me too. On sway the apps don't crash though.
Comment 7 Vlad Zahorodnii 2020-10-12 18:46:19 UTC
Relevant merge request https://invent.kde.org/plasma/kwayland-server/-/merge_requests/98
Comment 8 Lewis Lakerink 2020-10-12 23:10:06 UTC
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!
Comment 9 Vlad Zahorodnii 2020-10-13 06:00:42 UTC
No, I screwed the pooch with Qt versions. It's 5.15.2
Comment 10 Lewis Lakerink 2020-10-13 10:39:37 UTC
(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
Comment 11 Vlad Zahorodnii 2020-10-13 12:50:51 UTC
Great, thank you for testing.
Comment 12 Vlad Zahorodnii 2020-10-13 18:05:52 UTC
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
Comment 13 Vlad Zahorodnii 2020-10-13 18:06:18 UTC
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
Comment 14 Nicolas Fella 2020-10-19 19:52:06 UTC
*** Bug 427993 has been marked as a duplicate of this bug. ***
Comment 15 Vlad Zahorodnii 2020-10-26 09:00:44 UTC
*** Bug 427973 has been marked as a duplicate of this bug. ***
Comment 16 Vlad Zahorodnii 2020-10-26 16:06:51 UTC
*** Bug 427827 has been marked as a duplicate of this bug. ***
Comment 17 Nicolas Fella 2020-10-29 13:16:15 UTC
*** Bug 428421 has been marked as a duplicate of this bug. ***
Comment 18 Nicolas Fella 2020-10-29 13:18:26 UTC
*** Bug 428420 has been marked as a duplicate of this bug. ***
Comment 19 Nicolas Fella 2020-10-29 13:19:12 UTC
*** Bug 428422 has been marked as a duplicate of this bug. ***
Comment 20 Ilgaz Öcal 2021-02-20 09:53:18 UTC
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
Comment 21 Christian Hartmann 2021-02-20 10:16:24 UTC
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
Comment 22 Ilgaz Öcal 2021-02-21 04:47:20 UTC
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
Comment 23 Christian Hartmann 2021-03-19 21:53:14 UTC
Any news on this one here? I'm still experiencing these crashes
Comment 24 Vlad Zahorodnii 2021-03-26 08:46:02 UTC
https://invent.kde.org/plasma/kwayland-server/-/merge_requests/156 should help with plasmashell crashing.
Comment 25 Christian Hartmann 2021-03-26 14:19:05 UTC
(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 :-)
Comment 26 Vlad Zahorodnii 2021-04-07 12:07:34 UTC
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.
Comment 27 Ritesh Raj Sarraf 2021-05-24 09:03:10 UTC
(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
Comment 28 Nicolas Fella 2021-05-24 11:02:18 UTC
These are new symptoms, please open a new report for this
Comment 29 Ritesh Raj Sarraf 2021-05-24 11:30:32 UTC
(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.
Comment 30 Nate Graham 2021-05-24 18:39:43 UTC
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.
Comment 31 Christian Hartmann 2021-06-11 15:45:16 UTC
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?
Comment 32 Nate Graham 2021-06-14 18:35:38 UTC
Not to my knowledge. Go ahead and file one.
Comment 33 Christian Hartmann 2021-06-15 17:45:03 UTC
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.
Comment 34 Sven Guenther 2021-08-26 05:58:19 UTC
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