Since about 2025-11-21, I've been noticing quite frequent fails of KDE live image install tests for Rawhide updates. The failure seems to be caused by slitherer crashing. In anaconda.log, we see: 06:59:04,096 WRN ui.webui: web-ui: the webui-desktop script ended abruptly! 06:59:04,096 DBG ui.webui: web-ui: closing main loop 06:59:04,098 DBG ui.webui: web-ui: cockpit web view has finished running in the journal, we see: Nov 23 22:58:46 localhost-live slitherer[3647]: Failed to register with host portal QDBusError("org.freedesktop.portal.Error.Failed", "Could not register app ID: App info not found for 'org.fedoraproject.AnacondaInstaller'") Nov 23 22:58:46 localhost-live liveinst[3647]: libva error: /usr/lib64/dri/virtio_gpu_drv_video.so init failed Nov 23 22:58:46 localhost-live audit[3647]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3647 comm="slitherer" exe="/usr/bin/slitherer" sig=11 res=1 Nov 23 22:58:46 localhost-live kernel: slitherer[3647]: segfault at 2dc ip 00007fc97480ecab sp 00007ffd290db700 error 4 in libQt6WebEngineCore.so.6.10.1[15dcab,7fc9746b1000+a32a000] likely on CPU 1 (core 1, socket 0) Nov 23 22:58:46 localhost-live kernel: Code: 8d 7b 58 4c 89 e6 e8 04 15 c4 00 c6 83 e8 03 00 00 01 48 8d 05 3e 95 7c 0b 48 8b 00 48 8b 80 28 02 00 00 4c 8b a8 30 0b 00 00 <41> 8b 9d dc 02 00 00 85 db 0f 85 3e 01 00 00 4c 8d b5 50 ff ff ff Nov 23 22:58:46 localhost-live systemd-coredump[3771]: Process 3647 (slitherer) of user 1000 terminated abnormally with signal 11/SEGV, processing... I don't have the backtrace, I'd have to tweak openQA or reproduce this manually to get it. I'm not sure how useful it is for investigating a segfault, though. The earliest occurrences of this I can find are: * https://openqa.fedoraproject.org/tests/3982091 - 11-21 16:00 * https://openqa.stg.fedoraproject.org/tests/5592100 - 11-21 16:01 * https://openqa.stg.fedoraproject.org/tests/5592101 - 11-21 16:01 Those are all tests of https://bodhi.fedoraproject.org/updates/FEDORA-2025-9417bbae5b , so that seems like a reasonable guess as to the trigger. The prod failure was auto-restarted and passed on the retry, so that's why the update didn't get gated.
So far Neal tried rebuilding slitherer in case that would help, but it doesn't look like it did, because we saw the bug in testing of that very slitherer rebuild - https://openqa.fedoraproject.org/tests/4003219 .
So I'm confused what's going on here. Nothing changed code-wise, and it's pretty clear this broke with Qt 6.10.1, but *how* is as clear as mud.
I'd hoped it was related to https://qt-project.atlassian.net/browse/QTBUG-142186, but if it's still happening... :(
I *suspect* this must actually be a toolchain issue. gcc or glibc or something. I suspect that because I'm now seeing something similar in gnome-shell, and I think I saw something similar in something else recently (I'll track it down). Since about 2025-11-28, GNOME tests in openQA are failing sometimes because gnome-shell segfaults on login. The logs always look like this: Dec 04 08:11:03 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd-kcm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Dec 04 08:11:03 fedora gnome-shell[2088]: An object is already exported for the interface org.freedesktop.IBus.Service at /org/freedesktop/IBus/Panel Dec 04 08:11:03 fedora kernel: gnome-shell[2088]: segfault at 1012000e ip 00007f09a8f39145 sp 00007ffd4ac89620 error 4 in libgobject-2.0.so.0.8700.0[2f145,7f09a8f0a000+38000] likely on CPU 1 (core 1, socket 0) Dec 04 08:11:03 fedora gnome-shell[2088]: g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed Dec 04 08:11:03 fedora kernel: Code: 0f 84 8f 00 00 00 48 8b 07 48 85 c0 0f 84 a3 00 00 00 48 8b 10 48 81 fa fc 03 00 00 76 3f 48 89 d6 b8 01 00 00 00 48 83 e6 fc <f6> 46 0e 10 75 27 8b 7e 20 e8 8d 22 fd ff 48 89 c1 31 c0 48 8d 15 Dec 04 08:11:03 fedora gnome-shell[2088]: g_object_is_floating: assertion 'G_IS_OBJECT (object)' failed Dec 04 08:11:03 fedora gnome-shell[2088]: g_object_set_qdata_full: assertion 'G_IS_OBJECT (object)' failed Dec 04 08:11:03 fedora gnome-shell[2088]: g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed Dec 04 08:11:03 fedora gnome-shell[2088]: g_object_weak_ref: assertion 'G_IS_OBJECT (object)' failed Dec 04 08:11:03 fedora gnome-shell[2088]: g_object_add_toggle_ref: assertion 'G_IS_OBJECT (object)' failed Dec 04 08:11:03 fedora gnome-shell[2088]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Dec 04 08:11:03 fedora gnome-shell[2088]: instance with invalid (NULL) class pointer Dec 04 08:11:03 fedora gnome-shell[2088]: g_signal_connect_closure_by_id: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed Dec 04 08:11:03 fedora gnome-shell[2088]: instance with invalid (NULL) class pointer Dec 04 08:11:03 fedora gnome-shell[2088]: g_signal_connect_closure_by_id: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed Dec 04 08:11:03 fedora gnome-shell[2088]: instance with invalid (NULL) class pointer Dec 04 08:11:03 fedora gnome-shell[2088]: g_signal_connect_closure_by_id: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed Dec 04 08:11:03 fedora gnome-shell[2088]: instance with invalid (NULL) class pointer Dec 04 08:11:03 fedora gnome-shell[2088]: g_signal_connect_closure_by_id: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed Dec 04 08:11:03 fedora gnome-shell[2088]: instance with invalid (NULL) class pointer Dec 04 08:11:03 fedora gnome-shell[2088]: g_signal_connect_closure_by_id: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed Dec 04 08:11:03 fedora gnome-shell[2088]: instance with invalid (NULL) class pointer Dec 04 08:11:03 fedora gnome-shell[2088]: g_signal_connect_closure_by_id: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed Dec 04 08:11:03 fedora gnome-shell[2088]: instance with invalid (NULL) class pointer Dec 04 08:11:03 fedora gnome-shell[2088]: g_signal_connect_closure_by_id: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed Dec 04 08:11:03 fedora gnome-shell[2088]: instance with invalid (NULL) class pointer Dec 04 08:11:03 fedora gnome-shell[2088]: g_signal_connect_closure_by_id: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed Dec 04 08:11:03 fedora gnome-shell[2088]: instance with invalid (NULL) class pointer Dec 04 08:11:03 fedora gnome-shell[2088]: g_signal_connect_closure_by_id: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed Dec 04 08:11:03 fedora gnome-shell[2088]: instance with invalid (NULL) class pointer Dec 04 08:11:03 fedora gnome-shell[2088]: g_signal_connect_closure_by_id: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed Based on when it seems to have started happening, I *think* it was introduced with gnome-shell-49.1-3.fc44 - the first failure I can find (https://openqa.fedoraproject.org/tests/4013938) was with that gnome-shell, which was tagged on 2025-11-27. But all that build did was bump a dependency version. No code was changed. I checked glib2 as well, but that doesn't seem to line up - the last glib2 build tagged was Tue Nov 11 17:56:42 2025 glib2-2.87.0-1.fc44 , so if that was the trigger I'd expect to find failures between Nov 11 and Nov 28, but I can't find any. gnome-shell-49.1-2.fc44 (which I'm counting as 'good') was built with glibc 2.42.9000-7.fc44 and gcc 15.2.1-3.fc44 . gnome-shell-49.1-3.fc44 (which I'm theorizing is 'bad') was built with 2.42.9000-13.fc44 and gcc 15.2.1-4.fc44 . For slitherer we kinda suspect the trigger was the qt6 bump (including qt6-qtwebview) on 2025-11-21. That build was done with glibc 2.42.9000-11.fc44 and gcc 15.2.1-4.fc44. So...I guess we're looking at either something between glibc 2.42.9000-7.fc44 and glibc 2.42.9000-11.fc44 or something between gcc 15.2.1-3.fc44 and gcc 15.2.1-4.fc44 if my theory is correct? I guess I'll whack at this some more...I can try and do a build of gnome-shell using an older gcc/glibc, I guess. It'd be hard to do qt6 as I'd have to rebuild a lot of packages... CCing gcc and glibc maintainers in case they have any bright ideas. I do have a backtrace from one of the gnome-shell crashes (no idea how useful that is), I'll attach it. You can get a coredump from one of the gnome-shell crashes at https://openqa.fedoraproject.org/tests/4034927/file/_graphical_wait_login_2-coredump.tar.gz .
Created attachment 2117462 [details] backtrace from a gnome-shell segfault
hmm, but wait. The slitherer case seems to be happening on f43 as well, but we don't have any scary glibc or gcc changes there (I don't think). Seems to have started on f43 at least as early as 2025-11-23 - https://openqa.fedoraproject.org/tests/3985754 . That fits nicely with the push of qt 6.10.1 to f43 - https://bodhi.fedoraproject.org/updates/FEDORA-2025-b332f482fa#comment-4436466 . So maybe there really are two things...but then why did gnome-shell suddenly start crashing? Grump. I have filed the gnome-shell thing upstream - https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8877 - so will follow up on that one there...
RKWard crashed when starting with Qt 6.10.1. https://bugzilla.redhat.com/show_bug.cgi?id=2416541 The crashes were usually in QtWebEngineCore::ContentClientQt::SetGpuInfo at /usr/src/debug/qt6-qtwebengine-6.10.1-2.fc43.x86_64/src/core/content_client_qt.cpp:528. I think the problem might be in qtwebengine 6.10.1 as most of the top functions were in it. RKWard sometimes crashed with SIGTRAP with different traces in qtwebengine https://bugzilla.redhat.com/show_bug.cgi?id=2416541#c1 The problem didn't happen with QTWEBENGINE_CHROMIUM_FLAGS=--disable-gpu rkward as suggested by Thomas Friedrichsmeier. https://bugs.kde.org/show_bug.cgi?id=512460#c2 I reproduced the slitherer crash in a Rawhide KDE live image VM the second time I started the installer from Welcome Center. The trace looked similar to the first one I reported at https://bugzilla.redhat.com/show_bug.cgi?id=2416541 Core was generated by `/usr/bin/slitherer http://127.0.0.1/cockpit/@localhost/anaconda-webui/index.html'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f29d4807cab in QtWebEngineCore::ContentClientQt::SetGpuInfo(gpu::GPUInfo const&) () from /lib64/libQt6WebEngineCore.so.6 [Current thread is 1 (Thread 0x7f2a3be5d200 (LWP 4060))] (gdb) bt #0 0x00007f29d4807cab in QtWebEngineCore::ContentClientQt::SetGpuInfo(gpu::GPUInfo const&) () from /lib64/libQt6WebEngineCore.so.6 #1 0x00007f29d7c34869 in content::GpuDataManagerImplPrivate::UpdateGpuInfo(gpu::GPUInfo const&, std::optional<gpu::GPUInfo> const&) () from /lib64/libQt6WebEngineCore.so.6 #2 0x00007f29d7c2cdbb in content::GpuDataManagerImpl::UpdateGpuInfo(gpu::GPUInfo const&, std::optional<gpu::GPUInfo> const&) () from /lib64/libQt6WebEngineCore.so.6 #3 0x00007f29d7c44e04 in content::GpuProcessHost::DidInitialize(gpu::GPUInfo const&, gpu::GpuFeatureInfo const&, std::optional<gpu::GPUInfo> const&, std::optional<gpu::GpuFeatureInfo> const&, gfx::GpuExtraInfo const&) () from /lib64/libQt6WebEngineCore.so.6 #4 0x00007f29db0a2b58 in viz::GpuHostImpl::DidInitialize(gpu::GPUInfo const&, gpu::GpuFeatureInfo const&, std::optional<gpu::GPUInfo> const&, std::optional<gpu::GpuFeatureInfo> const&, gfx::GpuExtraInfo const&) () from /lib64/libQt6WebEngineCore.so.6 #5 0x00007f29d5ed9294 in viz::mojom::GpuHostStubDispatch::Accept(viz::mojom::GpuHost*, mojo::Message*) () from /lib64/libQt6WebEngineCore.so.6 #6 0x00007f29d9f66e32 in mojo::InterfaceEndpointClient::HandleValidatedMessage(mojo::Message*) () from /lib64/libQt6WebEngineCore.so.6 #7 0x00007f29d9f687be in mojo::MessageDispatcher::Accept(mojo::Message*) () from /lib64/libQt6WebEngineCore.so.6 #8 0x00007f29d9f66adc in mojo::InterfaceEndpointClient::HandleIncomingMessage(mojo::Message*) () from /lib64/libQt6WebEngineCore.so.6 #9 0x00007f29d9f6c0e2 in mojo::internal::MultiplexRouter::ProcessIncomingMessage(mojo::internal::MultiplexRouter::MessageWrapper*, mojo::internal::MultiplexRouter::ClientCallBehavior, base::SequencedTaskRunner*) () from /lib64/libQt6WebEngineCore.so.6 #10 0x0000000000000000 in ?? () I tried to install the qt6-qtwebengine debug rpms but they were about 2 GB and there wasn't enough free space in / in the live image. There might be some way around that I haven't tried yet like putting the debuginfod environment to /tmp though that is only 1.9 GB in the image.
I ran DEBUGINFOD_CACHE_PATH=/tmp/debuginfo coredumpctl gdb in Konsole, enter y to enable debuginfod, and cancelled debuginfo for packages other than qtwebengine so /tmp didn't become full with ctrl+c. The top of the trace was in the same function and line QtWebEngineCore::ContentClientQt::SetGpuInfo () at /usr/src/debug/qt6-qtwebengine-6.10.1-2.fc44.x86_64/src/core/content_client_qt.cpp:528 as the RKWard crashes. (gdb) bt #0 QtWebEngineCore::ContentClientQt::SetGpuInfo () at /usr/src/debug/qt6-qtwebengine-6.10.1-2.fc44.x86_64/src/core/content_client_qt.cpp:528 #1 0x00007f29d7c34869 in content::GpuDataManagerImplPrivate::UpdateGpuInfo () at ../../../../../src/3rdparty/chromium/content/browser/gpu/gpu_data_manager_impl_private.cc:1051 #2 0x00007f29d7c2cdbb in content::GpuDataManagerImpl::UpdateGpuInfo () at ../../../../../src/3rdparty/chromium/content/browser/gpu/gpu_data_manager_impl.cc:168 #3 0x00007f29d7c44e04 in content::GpuProcessHost::DidInitialize () at ../../../../../src/3rdparty/chromium/content/browser/gpu/gpu_process_host.cc:988 #4 0x00007f29db0a2b58 in viz::GpuHostImpl::DidInitialize () at ./../../../../../src/3rdparty/chromium/components/viz/host/gpu_host_impl.cc:498 #5 0x00007f29d5ed9294 in viz::mojom::GpuHostStubDispatch::Accept () at ./gen/services/viz/privileged/mojom/gl/gpu_host.mojom.cc:1297 #6 0x00007f29d9f66e32 in mojo::InterfaceEndpointClient::HandleValidatedMessage () at ../../../../../src/3rdparty/chromium/mojo/public/cpp/bindings/lib/interface_endpoint_client.cc:1052 #7 0x00007f29d9f687be in mojo::MessageDispatcher::Accept () at ../../../../../src/3rdparty/chromium/mojo/public/cpp/bindings/lib/message_dispatcher.cc:43 #8 0x00007f29d9f66adc in mojo::InterfaceEndpointClient::HandleIncomingMessage () at ../../../../../src/3rdparty/chromium/mojo/public/cpp/bindings/lib/interface_endpoint_client.cc:724 #9 0x00007f29d9f6c0e2 in mojo::internal::MultiplexRouter::ProcessIncomingMessage () at ../../../../../src/3rdparty/chromium/mojo/public/cpp/bindings/lib/multiplex_router.cc:1121 #10 0x00007f29d9f6f952 in mojo::internal::MultiplexRouter::Accept () at ../../../../../src/3rdparty/chromium/mojo/public/cpp/bindings/lib/multiplex_router.cc:734 #11 0x00007f29d9f687be in mojo::MessageDispatcher::Accept () at ../../../../../src/3rdparty/chromium/mojo/public/cpp/bindings/lib/message_dispatcher.cc:43 #12 0x00007f29d9f60311 in mojo::Connector::DispatchMessage () at ../../../../../src/3rdparty/chromium/mojo/public/cpp/bindings/lib/connector.cc:562 #13 0x00007f29d9f6100c in mojo::Connector::ReadAllAvailableMessages () at ../../../../../src/3rdparty/chromium/mojo/public/cpp/bindings/lib/connector.cc:620 #14 0x00007f29d9f6115e in mojo::Connector::OnHandleReadyInternal () at ../../../../../src/3rdparty/chromium/mojo/public/cpp/bindings/lib/connector.cc:452 #15 mojo::Connector::OnWatcherHandleReady () at ../../../../../src/3rdparty/chromium/mojo/public/cpp/bindings/lib/connector.cc:418 #16 0x00007f29d5e4e17e in base::RepeatingCallback<void (unsigned int)>::Run(unsigned int) const & () at ../../../../../src/3rdparty/chromium/base/functional/callback.h:344 #17 mojo::SimpleWatcher::DiscardReadyState () at ../../../../../src/3rdparty/chromium/mojo/public/cpp/system/simple_watcher.h:192 #18 0x00007f29d9f88d1d in base::RepeatingCallback<void (unsigned int, mojo::HandleSignalsState const&)>::Run(unsigned int, mojo::HandleSignalsState const&) const & () at ../../../../../src/3rdparty/chromium/base/functional/callback.h:344 #19 mojo::SimpleWatcher::OnHandleReady () at ../../../../../src/3rdparty/chromium/mojo/public/cpp/system/simple_watcher.cc:278 #20 0x00007f29d95f266e in base::OnceCallback<void ()>::Run() && () at ../../../../../src/3rdparty/chromium/base/functional/callback.h:156 #21 base::TaskAnnotator::RunTaskImpl () at ./../../../../../src/3rdparty/chromium/base/task/common/task_annotator.cc:209 #22 0x00007f29d9617671 in RunTask<base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::LazyNow*)::<lambda(perfetto::EventContext&)> > () at ../../../../../src/3rdparty/chromium/base/task/common/task_annotator.h:106 --Type <RET> for more, q to quit, c to continue without paging--c #23 base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl () at ./../../../../../src/3rdparty/chromium/base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:456 #24 0x00007f29d9618672 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork () at ./../../../../../src/3rdparty/chromium/base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:330 #25 0x00007f29d47ded0a in QtWebEngineCore::MessagePumpForUIQt::handleScheduledWork () at /usr/src/debug/qt6-qtwebengine-6.10.1-2.fc44.x86_64/src/core/browser_main_parts_qt.cpp:154 #26 QtWebEngineCore::MessagePumpForUIQt::MessagePumpForUIQt()::{lambda()#1}::operator()() const () at /usr/src/debug/qt6-qtwebengine-6.10.1-2.fc44.x86_64/src/core/browser_main_parts_qt.cpp:107 #27 std::__invoke_impl<void, QtWebEngineCore::MessagePumpForUIQt::MessagePumpForUIQt()::{lambda()#1}&>(std::__invoke_other, QtWebEngineCore::MessagePumpForUIQt::MessagePumpForUIQt()::{lambda()#1}&) () at /usr/include/c++/15/bits/invoke.h:63 #28 std::__invoke_r<void, QtWebEngineCore::MessagePumpForUIQt::MessagePumpForUIQt()::{lambda()#1}&>(QtWebEngineCore::MessagePumpForUIQt::MessagePumpForUIQt()::{lambda()#1}&) () at /usr/include/c++/15/bits/invoke.h:113 #29 std::_Function_handler<void (), QtWebEngineCore::MessagePumpForUIQt::MessagePumpForUIQt()::{lambda()#1}>::_M_invoke(std::_Any_data const&) () at /usr/include/c++/15/bits/std_function.h:292 #30 0x00007f2a3c792f55 in QObject::event(QEvent*) () from /lib64/libQt6Core.so.6 #31 0x00007f2a3c7364e8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt6Core.so.6 #32 0x00007f2a3c739b09 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib64/libQt6Core.so.6 #33 0x00007f2a3ca58fcf in postEventSourceDispatch(_GSource*, int (*)(void*), void*) () from /lib64/libQt6Core.so.6 #34 0x00007f2a3bb9b263 in g_main_context_dispatch_unlocked.lto_priv () from /lib64/libglib-2.0.so.0 #35 0x00007f2a3bba42e8 in g_main_context_iterate_unlocked.isra () from /lib64/libglib-2.0.so.0 #36 0x00007f2a3bba4493 in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #37 0x00007f2a3ca5880d in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib64/libQt6Core.so.6 #38 0x00007f2a3c743063 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib64/libQt6Core.so.6 #39 0x00007f2a3c73e819 in QCoreApplication::exec() () from /lib64/libQt6Core.so.6 #40 0x0000561ec95b9c46 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/slitherer-0~git20251108.d230dba-1.fc44.x86_64/main.cpp:110
you can just copy the coredump out then backtrace it in an installed system or mock chroot using the debuginfo server, that's how I usually do it these days. thanks for reproducing it! Neither I nor Neal has been able to do that yet.
Searching for QtWebEngineCore::ContentClientQt::SetGpuInfo in KDE crash reports shows reports for various apps, starting with Qt 6.10.1. So it doesn't look Fedora or toolchain specific
Is there an progress on any of those issues? Should we file a single upstream bug against qt or qtwebengine?
Someone who can reproduce the problem should file a Qt bug. I cannot reproduce it since it probably depends on the GPU. With the right hardware it should reproduce in a very simple QtWebengine demo though
well, that's the weird bit - openQA tests in qemu VMs using virtio graphics. I've tried to reproduce this in a local qemu VM with virtio graphics and I can't. No idea what the difference is, or if I just didn't try enough times...
Thanks. I reported the RKWard and slitherer crashes at https://qt-project.atlassian.net/browse/QTBUG-142497.
*** Bug 2420815 has been marked as a duplicate of this bug. ***
Vladimir Belyavsky wrote "Starting from Qt 6.10.1 we also see similar crashes on Windows in our Sentry. Most probably was introduced by https://codereview.qt-project.org/c/qt/qtwebengine/+/677351 " at https://qt-project.atlassian.net/browse/QTBUG-142497?focusedCommentId=2602402 That commit added the crashing line to QtWebEngineCore::ContentClientQt::SetGpuInfo (gdb) frame 5 #5 QtWebEngineCore::ContentClientQt::SetGpuInfo () at /usr/src/debug/qt6-qtwebengine-6.10.1-2.fc43.x86_64/src/core/content_client_qt.cpp:528 528 .status_values[gpu::GPU_FEATURE_TYPE_ACCELERATED_GL]; (gdb) l 523 m_gpuInfo = gpu_info; 524 525 auto *gpuChannelManager = content::GpuChildThread::instance()->gpu_channel_manager(); 526 const gpu::GpuFeatureStatus gpuCompositingStatus = 527 gpuChannelManager->gpu_feature_info() 528 .status_values[gpu::GPU_FEATURE_TYPE_ACCELERATED_GL]; 529 530 #if BUILDFLAG(IS_OZONE) 531 if (gpuCompositingStatus == gpu::kGpuFeatureStatusEnabled) { 532 // See entry 3 in //gpu/config/software_rendering_list.json
The patch at https://codereview.qt-project.org/c/qt/qtwebengine/+/702597 was marked as fixing https://qt-project.atlassian.net/browse/QTBUG-142497 and https://qt-project.atlassian.net/browse/QTBUG-142720 The problem was made a blocker for Qt 6.10.2 https://qt-project.atlassian.net/browse/QTBUG-142497?focusedCommentId=2604230
FEDORA-2026-d3f6fb57b0 (qt6-qtwebengine-6.10.1-3.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-d3f6fb57b0
<much rejoicing> Can we get a Rawhide build too? I'll keep an eye on it for a few days and see if the crashes go away.
FEDORA-2026-d3f6fb57b0 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-d3f6fb57b0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-d3f6fb57b0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-d3f6fb57b0 (qt6-qtwebengine-6.10.1-3.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
I reproduced the slitherer crash which had the same type of trace with qt6-qtwebengine-6.10.1-3.fc44 and Fedora-KDE-Desktop-Live-Rawhide-20260110.n.0.x86_64.iso in a QEMU/KVM VM in GNOME Boxes. RKWard crashed with the same kind of trace with qt6-qtwebengine-6.10.1-3.fc43. The patch qtwebengine-move-gpu-info-logging-to-gpu-thread.patch didn't seem to be applied. The %patch line wasn't added with this update as it was for other patches in the qt6-qtwebengine.spec https://src.fedoraproject.org/rpms/qt6-qtwebengine/c/5cba9df9f5fe02b4e5d2c2b8717e2fb5af742f98?branch=rawhide I reported this in more detail at https://bugzilla.redhat.com/show_bug.cgi?id=2416541#c5
FEDORA-2026-fc93919310 (qt6-qtwebengine-6.10.1-4.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-fc93919310
FEDORA-2026-fc93919310 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-fc93919310` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-fc93919310 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-fc93919310 (qt6-qtwebengine-6.10.1-4.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.