Created attachment 193742 [details] The output of gdb when reproducing the bug. Contains the output of run, thread apply all bt, and info threads DESCRIPTION When application is closed by alt+f4 or the close window button, the window closes, but some threads stay running and the process doesn't exit. STEPS TO REPRODUCE 1. Open discover 2. Close the discover window, seems to happen more often when closed while the window displays "loading..." OBSERVED RESULT The window closes, but the process doesn't fully exit. The process stays alive in the background, and a new discover window cannot be opened until that background process is manually killed. EXPECTED RESULT The window should close, and all threads and the main process should exit. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.7.1 KDE Frameworks Version: 6.27.0 Qt Version: 6.11.1 ADDITIONAL INFORMATION This behaviour was observed on a fresh install of arch linux, installed via archinstall with the plasma desktop profile. I'm not good with debugging tools, I'll try my best The program produces these logs when the bug is reproduced, and doesn't exit until a manual ctrl+c [lewis@archlinux ~]$ plasma-discover org.kde.plasma.libdiscover: OdrsReviewsBackend: Fetch ratings: false org.kde.plasma.libdiscover: error loading "packagekit-backend" "Cannot load library /usr/lib/qt6/plugins/discover/packagekit-backend.so: libpackagekitqt6.so.2: cannot open shared object file: No such file or directory" QJsonObject({"IID":"org.kde.discover.6.7.1.AbstractResourcesBackendFactory","archlevel":1,"className":"PackageKitBackendFactory","debug":false,"version":396032}) qrc:/qt/qml/org/kde/discover/qml/DiscoverWindow.qml:124: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: Embedded Controller No releases found QIODevice::read (QSslSocket): device not open I'll attach the output I could get from gdb Sorry if this isn't a good report or valid bug :( Seems similar to Bug ID 502828 which is marked as fixed. I tried it with all backends listed by plasma-discover --listbackends: Available backends: * flatpak-backend * fwupd-backend * kns-backend * packagekit-backend The only one that loads is the flatpak-backend, probably because my system is missing the others, however the bug appears using that backend whereas the report I mentioned says that it only occured using the kns-backend
So you only have the Flatpak backend installed, and the issue happens with that backend — but not 100% of the time? Is that right? It's weird because `plasma-discover --listbackends` should only list the backends you have. Is it possible you have more backends but they're broken because they're missing dependencies or something? Can you check?
Created attachment 193750 [details] Video of issue happening
(In reply to Nate Graham from comment #1) > So you only have the Flatpak backend installed, and the issue happens with > that backend — but not 100% of the time? Is that right? > > It's weird because `plasma-discover --listbackends` should only list the > backends you have. Is it possible you have more backends but they're broken > because they're missing dependencies or something? Can you check? I probably do have missing dependencies, I installed the backend for packagekit and the bug still works exactly the same, but I can't find where to get the dependencies for the others. It seems to happen 100% of the time when the application says "loading..." or while app icons are still loading I've attached a video of the issue happening Thank you :)
Thanks. That's weird and worrying that it happens with every backend, but hopefully that should help to make it easier to investigate. I'll let the Discover devs take it from here.
(In reply to Lewis Donaldson from comment #2) > Created attachment 193750 [details] > Video of issue happening I tried to replicate it on Fedora 44 as per the video, can't reproduce it on my end.
(In reply to Ty from comment #5) > (In reply to Lewis Donaldson from comment #2) > > Created attachment 193750 [details] > > Video of issue happening > > I tried to replicate it on Fedora 44 as per the video, can't reproduce it on > my end. Hmm that’s strange I’ve tried the bug on a new install of fedora KDE on both my Thinkpad T490 and Mac Pro from 2013, and it’s been the same as in the video for me. Could it maybe be to do with hardware? They’re both somewhat low-end devices by todays standards
Hi, I can't reproduce this with any backend either: > Operating System: Arch Linux > KDE Plasma Version: 6.7.80 > KDE Frameworks Version: 6.29.0 > Qt Version: 6.11.1 > Kernel Version: 7.0.14-arch1-1 (64-bit) > Graphics Platform: Wayland > Processors: 8 × Intel® Core™ Ultra 7 258V > Memory: 32 GiB of RAM (30.8 GiB usable) >Graphics Processor: Intel® Graphics
(In reply to Taras Oleksyn from comment #7) > Hi, > I can't reproduce this with any backend either: > > > Operating System: Arch Linux > > KDE Plasma Version: 6.7.80 > > KDE Frameworks Version: 6.29.0 > > Qt Version: 6.11.1 > > Kernel Version: 7.0.14-arch1-1 (64-bit) > > Graphics Platform: Wayland > > Processors: 8 × Intel® Core™ Ultra 7 258V > > Memory: 32 GiB of RAM (30.8 GiB usable) > >Graphics Processor: Intel® Graphics OK, I was able to reproduce this: seems like the crucial step is to close/quit Discover while it's fetching updates.
Setting to confirmed since this was reproduced.
*** Bug 522815 has been marked as a duplicate of this bug. ***
Hi! I’d also like to confirm that this bug is present on my system. I have Arch Linux installed via archinstall. Sometimes Discover closes normally and I can open it again. But after a few attempts to open and close it, the `plasma-discover` process freezes (I can see this via `htop`), and I can no longer open Discover through the KDE Plasma GUI until I kill the process.
The problem only occurs when I see the loading bar upon opening Discover. If I wait for the list of applications to load, Discover closes normally. I'm only using 2 backends [123@123-pc ~]$ plasma-discover --listbackends Available backends: * kns-backend * flatpak-backend
If needed, I'm ready to provide the necessary logs and run diagnostics while this issue is still reproducible on my PC. Just let me know which commands to run and under what conditions, and I'll post the log results here.
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 522815, bug 518264 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 522815, bug 518264 (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 522815, bug 518264 (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