(note: this happened with discover 5.18.2, but there's no such version in Bugzilla) I opened discover and it started fetching updates. After a few minutes, I realized it was just burning 200% CPU (i.e. two active threads) without making any progress. So I closed the window, but it kept running in the background and burning CPU. I was able to take this stacktrace of the main thread: #0 0x00007ffff51feea2 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0 #1 0x00007ffff60ff5a3 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /lib64/libQt5Core.so.5 #2 0x00007ffff60fc28f in QThreadPoolPrivate::waitForDone(QDeadlineTimer const&) () at /lib64/libQt5Core.so.5 #3 0x00007ffff60fc60a in QThreadPoolPrivate::waitForDone(int) () at /lib64/libQt5Core.so.5 #4 0x00007ffff60fc6c0 in QThreadPool::~QThreadPool() () at /lib64/libQt5Core.so.5 #5 0x00007fffc40a6bc1 in FwupdBackend::~FwupdBackend() (this=0x555556316390, __in_chrg=<optimized out>) at /usr/src/debug/plasma-discover-5.18.2-1.fc32.x86_64/libdiscover/backends/FwupdBackend/FwupdBackend.cpp:71 #6 0x00007fffc40a6c4d in FwupdBackend::~FwupdBackend() (this=0x555556316390, __in_chrg=<optimized out>) at /usr/src/debug/plasma-discover-5.18.2-1.fc32.x86_64/libdiscover/backends/FwupdBackend/FwupdBackend.cpp:63 #7 0x00007ffff7e78b3e in qDeleteAll<QTypedArrayData<AbstractResourcesBackend*>::const_iterator>(QTypedArrayData<AbstractResourcesBackend*>::const_iterator, QTypedArrayData<AbstractResourcesBackend*>::const_iterator) (end=<optimized out>, begin=<optimized out>) at /usr/include/qt5/QtCore/qalgorithms.h:319 #8 qDeleteAll<QVector<AbstractResourcesBackend*> >(QVector<AbstractResourcesBackend*> const&) (c=<optimized out>, c=@0x55555573b9c8: { d = 0x5555562ee070 }) at /usr/include/qt5/QtCore/qalgorithms.h:328 #9 ResourcesModel::~ResourcesModel() (this=0x55555573b9b0, __in_chrg=<optimized out>) at /usr/src/debug/plasma-discover-5.18.2-1.fc32.x86_64/libdiscover/resources/ResourcesModel.cpp:102 #10 0x00007ffff7e78b7d in ResourcesModel::~ResourcesModel() (this=0x55555573b9b0, __in_chrg=<optimized out>) at /usr/src/debug/plasma-discover-5.18.2-1.fc32.x86_64/libdiscover/resources/ResourcesModel.cpp:99 #11 0x00007ffff62ab164 in QObject::event(QEvent*) () at /lib64/libQt5Core.so.5 #12 0x00007ffff70c4e66 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5 #13 0x00007ffff6284860 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib64/libQt5Core.so.5 #14 0x00007ffff6287af3 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /lib64/libQt5Core.so.5 #15 0x00007ffff628adcf in QCoreApplication::exec() () at /lib64/libQt5Core.so.5 #16 0x000055555556b4fd in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/plasma-discover-5.18.2-1.fc32.x86_64/discover/main.cpp:179
Actually, the main thread is just idle. The two threads which were burning CPU are both executing code from libflatpak, so the bug is there, maybe.
Here's a nice backtrace with symbols: #0 0x00007ffff5d759cf in poll () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff5d759cf in poll () at /lib64/libc.so.6 #1 0x00007ffff48b0a8d in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0 #2 0x00007ffff48b0bc3 in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #3 0x00007fffc7a8f7a7 in ostree_repo_pull_with_options () at /lib64/libostree-1.so.1 #4 0x00007fffc7cf0f3c in repo_pull (self=0x5555562a2820, remote_name=0x7fffb80072e0 "flathub", dirs_to_pull=0x0, ref_to_fetch=0x7fffb80072a0 "appstream2/x86_64", rev_to_fetch=<optimized out>, token=0x0, results_to_fetch=<optimized out>, flatpak_flags=<optimized out>, flags=<optimized out>, progress=<optimized out>, cancellable=0x7fffb40065a0, error=0x7fffc61b1b48) at common/flatpak-dir.c:4869 #5 0x00007fffc7d0a275 in flatpak_dir_pull (self=0x55555629d320, state=0x7fffb8008940, ref=0x7fffb80072a0 "appstream2/x86_64", opt_rev=<optimized out>, opt_results=<optimized out>, subpaths=<optimized out>, token=<optimized out>, repo=0x5555562a2820, flatpak_flags=<optimized out>, flags=<optimized out>, progress=<optimized out>, cancellable=<optimized out>, error=<optimized out>) at common/flatpak-dir.c:5638 #6 0x00007fffc7d0e71d in flatpak_dir_update_appstream (self=self@entry=0x55555629d320, remote=remote@entry=0x5555562ac320 "flathub", arch=0x7fffc7d73962 "x86_64", arch@entry=0x0, out_changed=out_changed@entry=0x0, progress=progress@entry=0x7fffb8004d40, cancellable=cancellable@entry=0x7fffb40065a0, error=0x7fffc61b1c58) at common/flatpak-dir.c:4570 #7 0x00007fffc7d1fe94 in flatpak_installation_update_appstream_full_sync (self=<optimized out>, remote_name=0x5555562ac320 "flathub", arch=0x0, progress=<optimized out>, progress_data=0x0, out_changed=0x0, cancellable=0x7fffb40065a0, error=0x7fffc61b1c58) at common/flatpak-installation.c:2913 #8 0x00007fffc7dfd4d6 in FlatpakRefreshAppstreamMetadataJob::run() () at /usr/lib64/qt5/plugins/discover/flatpak-backend.so #9 0x00007ffff60f99b6 in QThreadPrivate::start(void*) () at /lib64/libQt5Core.so.5 #10 0x00007ffff51f8432 in start_thread () at /lib64/libpthread.so.0 #11 0x00007ffff5d80833 in clone () at /lib64/libc.so.6
I could reproduce "Fetching Updates..." hanging with 200% CPU usage 4 times in a row, but now Discover exits normally when I close the window (instead of lingering with 200% CPU usage).
Other versions of interest: KDE Frameworks 5.67.0 The xcb windowing system (WAT???) Qt 5.13.2 (built against 5.13.2)
Also relevant: flatpak-libs-1.6.2-1.fc32.x86_64 ostree-libs-2020.2-2.fc32.x86_64
New stacktrace with the the ostree debuginfo installed, showing that we are looping in libostree/ostree-repo-pull.c:4525 (gdb) bt #0 0x00007ffff5d7147f in write () at /lib64/libc.so.6 #1 0x00007ffff48fa41a in g_wakeup_signal () at /lib64/libglib-2.0.so.0 #2 0x00007ffff48ac594 in block_source () at /lib64/libglib-2.0.so.0 #3 0x00007ffff48b0878 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #4 0x00007ffff48b0af8 in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0 #5 0x00007ffff48b0bc3 in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #6 0x00007fffc3b4f7a7 in ostree_repo_pull_with_options (self=self@entry=0x5555560ac820, remote_name_or_baseurl=remote_name_or_baseurl@entry=0x7fffb80072e0 "flathub", options=options@entry=0x7fffb810e060, progress=progress@entry=0x7fffb8004d40, cancellable=cancellable@entry=0x7fffb40065a0, error=error@entry=0x7fffc2271b48) at src/libostree/ostree-repo-pull.c:4525 #7 0x00007fffc3da2f3c in repo_pull (self=0x5555560ac820, remote_name=0x7fffb80072e0 "flathub", dirs_to_pull=0x0, ref_to_fetch=0x7fffb80072a0 "appstream2/x86_64", rev_to_fetch=<optimized out>, token=0x0, results_to_fetch=<optimized out>, flatpak_flags=<optimized out>, flags=<optimized out>, progress=<optimized out>, cancellable=0x7fffb40065a0, error=0x7fffc2271b48) at common/flatpak-dir.c:4869 #8 0x00007fffc3dbc275 in flatpak_dir_pull (self=0x5555560a7b20, state=0x7fffb8008940, ref=0x7fffb80072a0 "appstream2/x86_64", opt_rev=<optimized out>, opt_results=<optimized out>, subpaths=<optimized out>, token=<optimized out>, repo=0x5555560ac820, flatpak_flags=<optimized out>, flags=<optimized out>, progress=<optimized out>, cancellable=<optimized out>, error=<optimized out>) at common/flatpak-dir.c:5638 #9 0x00007fffc3dc071d in flatpak_dir_update_appstream (self=self@entry=0x5555560a7b20, remote=remote@entry=0x5555560b6a50 "flathub", arch=0x7fffc3e25962 "x86_64", arch@entry=0x0, out_changed=out_changed@entry=0x0, progress=progress@entry=0x7fffb8004d40, cancellable=cancellable@entry=0x7fffb40065a0, error=0x7fffc2271c58) at common/flatpak-dir.c:4570 #10 0x00007fffc3dd1e94 in flatpak_installation_update_appstream_full_sync (self=<optimized out>, remote_name=0x5555560b6a50 "flathub", arch=0x0, progress=<optimized out>, progress_data=0x0, out_changed=0x0, cancellable=0x7fffb40065a0, error=0x7fffc2271c58) at common/flatpak-installation.c:2913 #11 0x00007fffe803a4d6 in FlatpakRefreshAppstreamMetadataJob::run() () at /usr/lib64/qt5/plugins/discover/flatpak-backend.so #12 0x00007ffff60f99b6 in QThreadPrivate::start(void*) () at /lib64/libQt5Core.so.5 #13 0x00007ffff51f8432 in start_thread () at /lib64/libpthread.so.0 #14 0x00007ffff5d80833 in clone () at /lib64/libc.so.6
Ok, it's stuck in this loop: /* Now await work completion */ while (!pull_termination_condition (pull_data)) g_main_context_iteration (pull_data->main_context, TRUE);
It was a bug in libcurl 7.69: https://bugzilla.redhat.com/show_bug.cgi?id=1811060 https://bugzilla.redhat.com/show_bug.cgi?id=1810989
Fedora has rolled back to curl-7.68