STEPS TO REPRODUCE Attempt launching Discover, either through the GUI or the CLI with `plasma-discover` OBSERVED RESULT Attempting to launch through the GUI simply results in a loading animation that lasts ~9 or so seconds, and then fails to launch Attempting to launch through the CLI returns `QThreadStorage: entry 2 destroyed before end of thread 0x558419476260 QThreadStorage: entry 1 destroyed before end of thread 0x558419476260` EXPECTED RESULT Discover launches. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Linux, Linux 6.19.6-zen1-1-zen KDE Plasma Version: 6.6.80 KDE Frameworks Version: 6.25.0 Qt Version: 6.10.2 ADDITIONAL INFORMATION Restarting the system fixes the issue, killing Discover's process from System Monitor does aswell, although, when this issue was first replicateable around 2-3 months ago, Discover would create an unkillable process. The issue however re-arises after some time.
I experienced the same issue on Fedora 43 with plasma-discover 6.6.3. It occurs after long uptime and is caused by a stuck plasma-discover process from a previous session. Running pkill -9 plasma-discover before launching fixes it without a reboot. I also have a stack trace from coredumpctl showing the crash occurring in LazyIconResolver::resolve → KIconLoader::queryIcons → deduplicateIconsByName if that's useful for debugging Stack trace of thread 3255: #0 0x00007f0154c813cc __pthread_kill_implementation (libc.so.6 + 0x743cc) #1 0x00007f0154c2715e raise (libc.so.6 + 0x1a15e) #2 0x00007f0157e220d6 _ZN6KCrash19defaultCrashHandlerEi (libKF6Crash.so.6 + 0x50d6) #3 0x00007f0154c27290 __restore_rt (libc.so.6 + 0x1a290) #4 0x00007f015540379d _ZN9QtPrivate14compareStringsE11QStringViewS0_N2Qt15CaseSensitivityE (libQt6Core.so.6 + 0x20379d) #5 0x00007f0155425738 _ZN9QtPrivate20QStringList_containsEPK5QListI7QStringE11QStringViewN2Qt15CaseSensitivityE (libQt6Core.so.6 + 0x225738) #6 0x00007f01559650c5 _ZN12_GLOBAL__N_1L22deduplicateIconsByNameERK5QListI7QStringE.lto_priv.0 (libKF6IconThemes.so.6 + 0xa0c5) #7 0x00007f0155970b3c _ZNK11KIconLoader10queryIconsEv (libKF6IconThemes.so.6 + 0x15b3c) #8 0x00007f015809ebd0 _ZN14AppStreamUtils18kIconLoaderHasIconERK7QString (libDiscoverCommon.so + 0x80bd0) #9 0x00007f00f573273f _ZN21AppPackageKitResource11resolveIconEv (packagekit-backend.so + 0x3d73f) #10 0x00007f01580840d1 _ZN16LazyIconResolver7resolveEv (libDiscoverCommon.so + 0x660d1) #11 0x00007f015808411d _ZN16LazyIconResolver11customEventEP6QEvent (libDiscoverCommon.so + 0x6611d)
(In reply to kovic from comment #0) > STEPS TO REPRODUCE > Attempt launching Discover, either through the GUI or the CLI with > `plasma-discover` Do you happen to know if this happens when updates are being installed? That's the reported trigger for bug 519683 Also, is there a crash for Discover in Crashed Process Viewer? If so, we'll need a backtrace. In bug 513569, the problem was linked to running with specific backends, in a specific order. At the time, it wasn't able to be reproduced on KDE Linux. Can you try these and see what happens? This may fail to bring up Discover killall -9 plasma-discover (flatpak first) plasma-discover --backends flatpak,fwupd This may bring up Discover successfully (fwupd first) killall -9 plasma-discover plasma-discover --backends fwupd,flatpak Let us know your results. Thanks!
(In reply to TraceyC from comment #2) Hello, fortunately I've not been able to replicate this bug for a while (around a month, now) It seems the bug that I was experiencing is more or less identical to bug 519683, with the same trigger No crash msg from what I can recall. Discover launches normally without any problems whether I use the argument 'flatpak,fwupd' or 'fwupd,flatpak'
Thanks for letting us know. I'm glad to hear things are working for you now!
Issue has resurfaced, as of KDE Linux 2026-07-28 Running pkill -9 plasma-discover before launching does in fact fix it without rebooting.
If that helped, it means the last-running instance of Discover got stuck and didn't fully quit.
Which also means https://invent.kde.org/plasma/discover/-/merge_requests/1355 will likely fix it.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/1393
Git commit a8b5538958594d90406aa0294d3934bcd06e7607 by Oliver Beard, on behalf of Aleix Pol. Committed on 15/08/2026 at 14:03. Pushed by olib into branch 'master'. DiscoverObject: Address quitting with concurrent KJobs We have a mechanism that disables random eventloops (KJobs) from quitting Discover outside of the user's interaction (see QCoreApplication::setQuitLockEnabled in discover/main.cpp). It so happens that we would at times have KJobs running also _after_ Discover's window closes. See how on the reported bugs they often describe it happening early in the startup process. This patch restores the Q*Application::quitLockEnabled property so that once Discover is with its task and we let go and QCoreApplication can let these jobs finish and eventually quit. It changes the DummyBackend to issue a KJob at the start to be able to reproduce this problem and eventually its fix. Related: bug 497419, bug 522245, bug 522815 M +2 -0 discover/DiscoverObject.cpp M +22 -0 libdiscover/backends/DummyBackend/DummyBackend.cpp https://invent.kde.org/plasma/discover/-/commit/a8b5538958594d90406aa0294d3934bcd06e7607
Git commit 0d0a1d35c715838f585590d54a1a9d5b14cbd151 by Oliver Beard. Committed on 15/08/2026 at 14:11. Pushed by olib into branch 'Plasma/6.7'. DiscoverObject: Address quitting with concurrent KJobs We have a mechanism that disables random eventloops (KJobs) from quitting Discover outside of the user's interaction (see QCoreApplication::setQuitLockEnabled in discover/main.cpp). It so happens that we would at times have KJobs running also _after_ Discover's window closes. See how on the reported bugs they often describe it happening early in the startup process. This patch restores the Q*Application::quitLockEnabled property so that once Discover is with its task and we let go and QCoreApplication can let these jobs finish and eventually quit. It changes the DummyBackend to issue a KJob at the start to be able to reproduce this problem and eventually its fix. Related: bug 497419, bug 522245, bug 522815 (cherry picked from commit a8b5538958594d90406aa0294d3934bcd06e7607) Co-authored-by: Aleix Pol <aleixpol@kde.org> M +2 -0 discover/DiscoverObject.cpp M +22 -0 libdiscover/backends/DummyBackend/DummyBackend.cpp https://invent.kde.org/plasma/discover/-/commit/0d0a1d35c715838f585590d54a1a9d5b14cbd151
Git commit 6bb252afbfef7bc413824ee153285e498b669801 by Oliver Beard. Committed on 15/08/2026 at 14:10. Pushed by olib into branch 'Plasma/6.6'. DiscoverObject: Address quitting with concurrent KJobs We have a mechanism that disables random eventloops (KJobs) from quitting Discover outside of the user's interaction (see QCoreApplication::setQuitLockEnabled in discover/main.cpp). It so happens that we would at times have KJobs running also _after_ Discover's window closes. See how on the reported bugs they often describe it happening early in the startup process. This patch restores the Q*Application::quitLockEnabled property so that once Discover is with its task and we let go and QCoreApplication can let these jobs finish and eventually quit. It changes the DummyBackend to issue a KJob at the start to be able to reproduce this problem and eventually its fix. Related: bug 497419, bug 522245, bug 522815 (cherry picked from commit a8b5538958594d90406aa0294d3934bcd06e7607) Co-authored-by: Aleix Pol <aleixpol@kde.org> M +2 -0 discover/DiscoverObject.cpp M +22 -0 libdiscover/backends/DummyBackend/DummyBackend.cpp https://invent.kde.org/plasma/discover/-/commit/6bb252afbfef7bc413824ee153285e498b669801