Fedora 43 KDE, Plasma 6.6.3/6.6.4
After launching Discover and closing the window trying to open it again causes the loading animation in the task manager tray to activate for a few seconds before silently giving up. Discover doesn’t exactly crash, more like hangs up, because it still shows up in the System Monitor process list (and in fact I have to manually kill Discover from there so I can restart it). journalctl output is not very informative:
Apr 14 14:57:54 fedora systemd[1521]: Started app-org.kde.discover@1ca244efd76b4758bf42cf33d345314a.service - Discover - Software Centre.
Apr 14 14:57:54 fedora plasma-discover[32235]: QThreadStorage: entry 2 destroyed before end of thread 0x556e0192fe00
Apr 14 14:57:54 fedora plasma-discover[32235]: QThreadStorage: entry 1 destroyed before end of thread 0x556e0192fe00
This (or something similar) also occasionally happens to System Settings, but not often enough for me to reliably reproduce. It happens every time to Discover though.
I’ll just bombard you with some relevant questions first. This will help us get to the bottom of the problem as quickly as possible, as that is convenient for both of us.
Does this affect any other Qt apps than Discover and occasionally System Settings?
What about non-Qt apps (that is, apps that do not share the look, feel, and theming of Discover and System Settings)?
Have you encountered any other problems with the system?
For how long have you used Fedora and this system?
Do you recall having to downgrade any packages?
Have you been mixing repositories (for instance, Copr)?
Is the system up to date (dnf check-update)?
What kind of hardware (AMD, NVIDIA, Intel) is in the system (provide specific names, if possible)?
Do you run X11 or Wayland (echo $XDG_SESSION_TYPE)?
Do you recall manually installing any drivers (GPU drivers, for instance)?
What kernel version (run uname -r in a shell) are you running?
Some issues using external Desktop Effects (blur forks), but it doesn’t seem related (and I’m pretty sure Discover was doing this before I installed any of that)
About a week, used to run OpenSUSE (but not on this machine)
No, don’t think so
A bit, here’s dnf repo info:
copr:copr.fedorainfracloud.org:ama1470:kwin-effects-glass Copr repo for kwin-effects-glass owned by ama1470
copr:copr.fedorainfracloud.org:deltacopy:darkly Copr repo for darkly owned by deltacopy
copr:copr.fedorainfracloud.org:ekaaty:kde-extras Copr repo for kde-extras owned by ekaaty
copr:copr.fedorainfracloud.org:hazel-bunny:ricing Copr repo for ricing owned by hazel-bunny
copr:copr.fedorainfracloud.org:infinality:kwin-effects-better-blur-dx Copr repo for kwin-effects-better-blur-dx owned by infinality
copr:copr.fedorainfracloud.org:phracek:PyCharm Copr repo for PyCharm owned by phracek
copr:copr.fedorainfracloud.org:sunwire:envycontrol Copr repo for envycontrol owned by sunwire
fedora Fedora 43 - x86_64
fedora-cisco-openh264 Fedora 43 openh264 (From Cisco) - x86_64
gitlab.com_paulcarroty_vscodium_repo gitlab.com_paulcarroty_vscodium_repo
rpmfusion-free RPM Fusion for Fedora 43 - Free
rpmfusion-free-updates RPM Fusion for Fedora 43 - Free - Updates
rpmfusion-nonfree RPM Fusion for Fedora 43 - Nonfree
rpmfusion-nonfree-nvidia-driver RPM Fusion for Fedora 43 - Nonfree - NVIDIA Driver
rpmfusion-nonfree-steam RPM Fusion for Fedora 43 - Nonfree - Steam
rpmfusion-nonfree-updates RPM Fusion for Fedora 43 - Nonfree - Updates
throne-repo Throne RPM repo
updates Fedora 43 - x86_64 - Updates
vivaldi vivaldi
Yep
12th Gen Intel(R) Core™ i7-12800H, NVIDIA RTX A1000 (running in hybrid GPU mode)
I gotta say, you’ve got quite the nice hardware. Never actually seen someone have an RTX A1000 before. Anyway. Did you encounter any issues before you applied all the KWin theming through the Copr repositories? I would bet my money on that being the core issue here. Second, try running the application KPatience (it’s a solitaire game written with Qt). Does that launch fine? Also, if you know how, check whether Discover actually opens fine with your KWin effects and whatnot disabled.
Ah, well it’s the laptop version of A1000, forgot to put that in lol
Just checked that uninstalling kwin-effects-glass and kwin-effects-better-blur-dx doesn’t seem to fix this, don’t think I have any other external KWin effects or scripts active. I did notice something else when restarting the session though: plasmashell crash notification upon login, and looks like it has happened a couple of times before that, though not consistently. Not sure if it’s plasma having trouble shutting down when I’m logging out or plasma crashing upon logging in and then recovering. Here’s the error message (without the long stack trace):
Ahoy we’re getting somewhere! That crash is a segmentation fault; accessing memory it shouldn’t. I’m guessing that there’s also something else going on. Test these out. Note that if this doesn’t work, find the new plasmashell process ID (pgrep plasmashell): coredumpctl info 1988 coredumpctl gdb 1988
and inside gbd, run bt thread apply all bt.
We need to see what’s going wrong with that backtrace.
It’s probably a compositor/theme/effect/graphics problem that’s causing you all these headaches. But we need a backtrace. You may also attempt a backtrace on Discover; you’ll need the process ID, though.
(gdb) bt
#0 0x00007f04fc4813cc in __pthread_kill_implementation () from /lib64/libc.so.6
#1 0x00007f04fc42715e in raise () from /lib64/libc.so.6
#2 0x00007f04ffafd0d6 in KCrash::defaultCrashHandler(int) () from /lib64/libKF6Crash.so.6
#3 <signal handler called>
#4 0x00007f04cfc48061 in blorp_setup_binding_table () from /lib64/libgallium-25.3.6.so
#5 0x00007f04cfc4be77 in blorp_exec () from /lib64/libgallium-25.3.6.so
#6 0x00007f04cfc4cb56 in iris_blorp_exec () from /lib64/libgallium-25.3.6.so
#7 0x00007f04cfbf39ba in do_blorp_blit () from /lib64/libgallium-25.3.6.so
#8 0x00007f04cfbf49c7 in blorp_copy () from /lib64/libgallium-25.3.6.so
#9 0x00007f04cfbbe364 in iris_copy_region () from /lib64/libgallium-25.3.6.so
#10 0x00007f04cfbb8ccf in iris_transfer_flush_region () from /lib64/libgallium-25.3.6.so
#11 0x00007f04cfbb8f5a in iris_transfer_unmap () from /lib64/libgallium-25.3.6.so
#12 0x00007f04cf5629a9 in u_default_texture_subdata () from /lib64/libgallium-25.3.6.so
#13 0x00007f04ce730ea0 in st_TexSubImage () from /lib64/libgallium-25.3.6.so
#14 0x00007f04ce700ef3 in texture_sub_image () from /lib64/libgallium-25.3.6.so
#15 0x00007f04ce704476 in texsubimage_err () from /lib64/libgallium-25.3.6.so
#16 0x00007f04ce70b129 in _mesa_TexSubImage2D () from /lib64/libgallium-25.3.6.so
#17 0x00007f04fd733f6b in QRhiGles2::executeCommandBuffer(QRhiCommandBuffer*) () from /lib64/libQt6Gui.so.6
#18 0x00007f04fd736457 in QRhiGles2::endFrame(QRhiSwapChain*, QFlags<QRhi::EndFrameFlag>) () from /lib64/libQt6Gui.so.6
#19 0x00007f04fd58a15f in QRhi::endFrame(QRhiSwapChain*, QFlags<QRhi::EndFrameFlag>) () from /lib64/libQt6Gui.so.6
#20 0x00007f04fe9c1037 in QSGRenderThread::syncAndRender() () from /lib64/libQt6Quick.so.6
#21 0x00007f04fe9c2463 in QSGRenderThread::run() () from /lib64/libQt6Quick.so.6
#22 0x00007f04fccd406e in QThreadPrivate::start(void*) () from /lib64/libQt6Core.so.6
#23 0x00007f04fc47f464 in start_thread () from /lib64/libc.so.6
#24 0x00007f04fc5025ec in __clone3 () from /lib64/libc.so.6
thread apply all bt prouces way too much output to paste (83 threads), should I grep for anything specific?
Your plasmashell crashes (and probably Discover crashes as well, although not 100% certain) have to do with the Intel Mesa Gallium Iris graphics driver path (driver bug), not any software bug. Roughly what happened is that Plasma was rendering a Qt Quick scene, submitted a frame, and the texture copy (or something similar) failed. It’s not a far-fetched guess to say that this is a GPU driver issue. Those are notoriously difficult to fix. You may (1) wait for a new driver release or (2) return to a previous version that worked fine, or (3) install a bleeding-edge dev build. If you can deal with Discover not working, you’ll probably be fine. I’d just wait for a GPU driver update or manually install the very latest dev build to see if that fixes the issue.
EDIT: Maybe I didn’t stress enough that if you previously (like a month or so ago) had a working driver, just go back to using that.
Well, I only installed Fedora last week and I think Discover behaved like this out of the box. Also as I said Discover isn’t really crashing (and I can indeed use it, I just have to not close the window or to kill the process every time I do), so I’m honestly not sure if this is actually caused by the same issue as the occasional plasmashell crashes.
Is there some way to track the execution of Discover on a deeper level than just by running journalctl -f before launching it?
There are command tools that do all that discover does if you are comfortable with linux command line. THey are also easier to reason about when they report errors.
Just tagging onto this thread which seems unresolved. I’m having seemingly the same issue:
$ /usr/bin/plasma-discover
QThreadStorage: entry 2 destroyed before end of thread 0x55e2ac4a4b00
QThreadStorage: entry 1 destroyed before end of thread 0x55e2ac4a4b00
Fails silently from GUI.
Truly confusing. I have noticed this sporadically with other apps (but as I type this it’s plasma-discover that is the issue). Yesterday settings was misbehaving.
Any insights appreciated.
Operating System: Fedora Linux 44
KDE Plasma Version: 6.6.4
KDE Frameworks Version: 6.26.0
Qt Version: 6.10.3
Kernel Version: 7.0.4-200.fc44.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 28 × Intel® Core™ i7-14700K
Memory: 64 GiB of RAM (62.5 GiB usable)
Graphics Processor 1: Intel® Graphics
Graphics Processor 2: NVIDIA GeForce RTX 4070 Ti SUPER
Manufacturer: System76
Product Name: Thelio Mira
System Version: thelio-mira-b4.1
Editing to add: I was just able to start discover, but only by right-click starting an update from the toolbar - weird). After that successfully worked, I can launch from GUI again.
I got the following when trying a CLI launch while the GUI version was already launched (and the CLI launch failed)
$ /usr/bin/plasma-discover
org.kde.plasma.libdiscover: OdrsReviewsBackend: Fetch ratings: false
adding empty sources model QStandardItemModel(0x55df8c498f70)
qrc:/qt/qml/org/kde/discover/qml/DiscoverWindow.qml:119:5: QML Shortcut: Shortcut: Only binding to one of multiple key bindings associated with 15. Use 'sequences: [ <key> ]' to bind to all of them.
qt.qpa.services: Failed to register with host portal QDBusError("org.freedesktop.portal.Error.Failed", "Could not register app ID: Connection already associated with an application ID")
fwupd: Device not supported: Thelio Io 2 is not updatable as requires a non-generic request
fwupd: Device not supported: Thelio Io 2
Killing the GUI then allowed the CLI to work.
So… was the toolbar version preventing the GUI from launching? If so, why would that happen?
Operating System: Fedora Linux 44
KDE Plasma Version: 6.6.4
KDE Frameworks Version: 6.26.0
Qt Version: 6.10.3
Kernel Version: 6.19.14-300.fc44.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 22 × Intel® Core™ Ultra 7 155H
Memory: 32 GiB of RAM (30.8 GiB usable)
Graphics Processor: Intel® Arc
Manufacturer: Framework
Product Name: Laptop 13 (Intel Core Ultra Series 1)
System Version: A5
Same solution; quitting the systray DiscoverNotifier icon or killing DiscoverNotifier fixes launching the Discover GUI, whether from CLI or launcher.
journalctl:
May 13 17:14:08 framework-laptop systemd[2711]: Started app-org.kde.discover@fd14cb369b8443b981bc5db3af28ee61.service - Discover - Software Center.
May 13 17:14:09 framework-laptop plasma-discover[458170]: QThreadStorage: entry 2 destroyed before end of thread 0x5586f4d92280
May 13 17:14:09 framework-laptop plasma-discover[458170]: QThreadStorage: entry 1 destroyed before end of thread 0x5586f4d92280
May 13 17:14:41 framework-laptop DiscoverNotifier[3787]: QProcess: Destroyed while process ("plasma-discover") is still running.
May 13 17:14:41 framework-laptop systemd[2711]: app-org.kde.discover.notifier@autostart.service: Consumed 1min 3.440s CPU time over 1d 13h 32min 35.416s wall clock time, 1.4G memory peak, 1.2G memory swap peak.
L1-3 are an attempt to launch Discover while DiscoverNotifier is running. L4-5 is emitted when DiscoverNotifier is quit. Discover fails to launch before that point and succeeds after it.
EDIT: DiscoverNotifier is package plasma-discover-notifier and can be removed separately from Discover, so I’ve done that. Never was effective or useful anyway, as it seemed to be permanently wedged in “Applying unattended updates…” but never applying any updates.
