Description of problem: GS eats 100% CPU on background. When killed it's started again after a while and continues to drain my resources. bt: (gdb) thread apply all bt full Thread 5 (Thread 0x7f71b77fe700 (LWP 102781)): #0 0x00007f71d6c089ac in read () at /lib64/libpthread.so.0 #1 0x00007f71d7b0135f in g_wakeup_acknowledge () at /lib64/libglib-2.0.so.0 #2 0x00007f71d7ab75c8 in g_main_context_check () at /lib64/libglib-2.0.so.0 #3 0x00007f71d7ab7a33 in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0 #4 0x00007f71d7ab7bc3 in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #5 0x00007f71c58a07a7 in ostree_repo_pull_with_options () at /lib64/libostree-1.so.1 #6 0x00007f71c5966f3c in repo_pull () at /lib64/libflatpak.so.0 #7 0x00007f71c5980275 in flatpak_dir_pull () at /lib64/libflatpak.so.0 #8 0x00007f71c5985129 in flatpak_dir_update_appstream () at /lib64/libflatpak.so.0 #9 0x00007f71c5995e94 in flatpak_installation_update_appstream_full_sync () at /lib64/libflatpak.so.0 #10 0x00007f71c5a71a4b in gs_flatpak_refresh_appstream_remote (self=0x555e9ad47020, remote_name=0x7f719400b7a0 "flathub", cancellable=0x7f71a80b00a0, error=0x7f71b77fd930) at ../plugins/flatpak/gs-flatpak.c:876 str = 0x7f719400e270 "Getting flatpak metadata for flathub…" app_dl = 0x7f71a401e740 phelper = 0x555e9abd3a60 error_local = 0x0 #11 0x00007f71c5a77cbb in gs_flatpak_refresh_appstream (error=0x7f71b77fd9d8, cancellable=0x7f71a80b00a0, cache_age=86400, self=0x555e9ad47020) at ../plugins/flatpak/gs-flatpak.c:944 tmp = 186432 file = 0x0 appstream_fn = 0x0 locker = 0x555e9ad47060 remote_name = 0x7f719400b7a0 "flathub" error_local = 0x0 file_timestamp = 0x555e9a949280 xremote = 0x7f71a00036d0 i = 2 ret = <optimized out> xremotes = 0x555e9ab79da0 #12 gs_flatpak_refresh (self=0x555e9ad47020, cache_age=cache_age@entry=86400, cancellable=cancellable@entry=0x7f71a80b00a0, error=error@entry=0x7f71b77fd9d8) at ../plugins/flatpak/gs-flatpak.c:1536 #13 0x00007f71c5a7afe5 in gs_plugin_refresh (plugin=<optimized out>, cache_age=86400, cancellable=0x7f71a80b00a0, error=0x7f71b77fd9d8) at ../plugins/flatpak/gs-plugin-flatpak.c:233 flatpak = <optimized out> i = 0 priv = 0x555e9ab527e0 #14 0x0000555e9a4864d3 in gs_plugin_loader_call_vfunc (helper=0x7f71b02a0980, plugin=0x555e9a95ef50, app=0x0, list=0x7f71a4200b00, refine_flags=0, cancellable=0x7f71a80b00a0, error=0x7f71b77fdad8) at ../lib/gs-plugin-loader.c:671 plugin_func = 0x7f71c5a7af90 <gs_plugin_refresh> action = GS_PLUGIN_ACTION_REFRESH ret = 1 func = 0x7f71c5a7af90 <gs_plugin_refresh> error_local = 0x0 timer = 0x7f7194007720 #15 0x0000555e9a4866fa in gs_plugin_loader_run_results (helper=helper@entry=0x7f71b02a0980, cancellable=cancellable@entry=0x7f71a80b00a0, error=error@entry=0x7f71b77fdad8) at ../lib/gs-plugin-loader.c:1081 plugin = 0x555e9a95ef50 i = 15 priv = 0x555e9a95e8f0 #16 0x0000555e9a488083 in gs_plugin_loader_process_thread_cb (task=0x555e9afbac80, object=0x555e9a95e9a0, task_data=0x7f71b02a0980, cancellable=0x7f71a80b00a0) at ../lib/gs-plugin-loader.c:3081 error = 0x0 --Type <RET> for more, q to quit, c to continue without paging-- helper = 0x7f71b02a0980 dedupe_flags = <optimized out> list = 0x7f71a4200b00 action = GS_PLUGIN_ACTION_REFRESH plugin_loader = 0x555e9a95e9a0 priv = 0x555e9a95e8f0 filter_flags = <optimized out> refine_flags = <optimized out> add_to_pending_array = <optimized out> #17 0x00007f71d7938c62 in g_task_thread_pool_thread () at /lib64/libgio-2.0.so.0 #18 0x00007f71d7ae1f5a in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0 #19 0x00007f71d7ae1652 in g_thread_proxy () at /lib64/libglib-2.0.so.0 #20 0x00007f71d6bfe432 in start_thread () at /lib64/libpthread.so.0 #21 0x00007f71d6b2a833 in clone () at /lib64/libc.so.6 Thread 4 (Thread 0x7f71c670d700 (LWP 101900)): #0 0x00007f71d6b1f9cf in poll () at /lib64/libc.so.6 #1 0x00007f71d7ab7a8d in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0 #2 0x00007f71d7ab7bc3 in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #3 0x00007f71c671e01d in dconf_gdbus_worker_thread () at /usr/lib64/gio/modules/libdconfsettings.so #4 0x00007f71d7ae1652 in g_thread_proxy () at /lib64/libglib-2.0.so.0 #5 0x00007f71d6bfe432 in start_thread () at /lib64/libpthread.so.0 #6 0x00007f71d6b2a833 in clone () at /lib64/libc.so.6 Thread 3 (Thread 0x7f71c7752700 (LWP 101897)): #0 0x00007f71d6b1f9cf in poll () at /lib64/libc.so.6 #1 0x00007f71d7ab7a8d in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0 #2 0x00007f71d7ab7e0b in g_main_loop_run () at /lib64/libglib-2.0.so.0 #3 0x00007f71d79a378a in gdbus_shared_thread_func () at /lib64/libgio-2.0.so.0 #4 0x00007f71d7ae1652 in g_thread_proxy () at /lib64/libglib-2.0.so.0 #5 0x00007f71d6bfe432 in start_thread () at /lib64/libpthread.so.0 #6 0x00007f71d6b2a833 in clone () at /lib64/libc.so.6 Thread 2 (Thread 0x7f71c7f53700 (LWP 101895)): #0 0x00007f71d6b1f9cf in poll () at /lib64/libc.so.6 #1 0x00007f71d7ab7a8d in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0 #2 0x00007f71d7ab7bc3 in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #3 0x00007f71d7ab7c11 in glib_worker_main () at /lib64/libglib-2.0.so.0 #4 0x00007f71d7ae1652 in g_thread_proxy () at /lib64/libglib-2.0.so.0 #5 0x00007f71d6bfe432 in start_thread () at /lib64/libpthread.so.0 #6 0x00007f71d6b2a833 in clone () at /lib64/libc.so.6 Thread 1 (Thread 0x7f71d4f4a580 (LWP 101885)): #0 0x00007f71d6b1f9cf in poll () at /lib64/libc.so.6 #1 0x00007f71d7ab7a8d in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0 #2 0x00007f71d7ab7bc3 in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #3 0x00007f71d796680d in g_application_run () at /lib64/libgio-2.0.so.0 #4 0x0000555e9a42bd77 in main (argc=2, argv=0x7ffcd1032718) at ../src/gs-main.c:48 status = 0 appinfo = 0x555e9a95e820 application = 0x555e9a92f0f0 debug = 0x555e9a923e00 (gdb)
I have been experiencing same issue with Flatpak and I've been able to track this down to curl package. When I downgrade to curl-7.68.0-2.fc32 from curl-7.69.0-1.fc32, then it just works.
Some busy looping could have been fixed by the following upstream commit: https://github.com/curl/curl/commit/2258b7bc Do we have a self-contained reproducer? I do not use gnome-software or flatpak myself...
There is going to be a follow-up release on Wednesday: https://curl.haxx.se/mail/lib-2020-03/0032.html I believe it will fix this bug.
This commit seems to fix this issue https://github.com/curl/curl/commit/8aa04e9a24932b830bc5eaf6838dea5a3329341e. I did a test build for myself and I was able to successfuly install an app.
Thank you for finding it out, Jan! I will put it to rawhide temporarily until it is replaced by the bugfix release on Wednesday.
dist-git commit: https://src.fedoraproject.org/rpms/curl/c/fbcad9a3
Can we get a fix for F32 too?
Fedora 32 is not affected by this bug unless you kept curl-7.69.0-1.fc32 from the update that was unpushed 3 days ago. Anyway, curl-7.69.1-1.fc32 is currently being built: https://koji.fedoraproject.org/koji/buildinfo?buildID=1476496
I struggle with this on F32 as well. :) And two more users who updated on F32 this days. https://bugzilla.redhat.com/show_bug.cgi?id=1811292
Sorry for the breakage! Please check whether curl-7.69.1-1.fc32 works better for you.
FEDORA-2020-8c3fc658af has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8c3fc658af
+1. Works fine with FEDORA-2020-8c3fc658af update.
curl-7.69.1-1.fc32 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8c3fc658af
curl-7.69.1-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, please make note of it in this bug report.