SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** After fixing the other issues with the upgrade to Plasma 6 on KDE Neon through the terminal, Discover will not launch via attempting to launch through any method (launcher, krunner, terminal, etc). An instance of the application shows as running in the System Monitor, but there is no window or other visible sign that an instance of Discover is running. STEPS TO REPRODUCE 1. Attempt to launch Discover by any means (click on launcher, run "plasma-discover" in terminal, launch from krunner, etc) 2. Wait for Discover to finish launching to find no window opens 3. Open System Monitor to notice that it shows Discover as running OBSERVED RESULT Discover fails to provide any usable interface to do anything with. EXPECTED RESULT Discover launches and is usable. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon 6.0 (available in About System) KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION
(In reply to bmhieserich from comment #0) > SUMMARY > *** > NOTE: If you are reporting a crash, please try to attach a backtrace with > debug symbols. > See > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > How_to_create_useful_crash_reports > *** > After fixing the other issues with the upgrade to Plasma 6 on KDE Neon > through the terminal, Discover will not launch via attempting to launch > through any method (launcher, krunner, terminal, etc). An instance of the > application shows as running in the System Monitor, but there is no window > or other visible sign that an instance of Discover is running. > > STEPS TO REPRODUCE > 1. Attempt to launch Discover by any means (click on launcher, run > "plasma-discover" in terminal, launch from krunner, etc) > 2. Wait for Discover to finish launching to find no window opens > 3. Open System Monitor to notice that it shows Discover as running > > OBSERVED RESULT > Discover fails to provide any usable interface to do anything with. > > EXPECTED RESULT > Discover launches and is usable. > > SOFTWARE/OS VERSIONS > Linux/KDE Plasma: KDE Neon 6.0 > (available in About System) > KDE Plasma Version: 6.0.0 > KDE Frameworks Version: 6.0.0 > Qt Version: 6.6.2 > > ADDITIONAL INFORMATION I had the same situation myself. In addition to what they said, I had an update notifier from Discover in my systray that worked, but I couldn't launch the app from it.
+1 - I also upgraded this morning via Discover and have this problem. User KDE Neon, not doing any funny business... just pressed the "upgrade" button this morning from latest stable Plasma without realizing how much would break. I can see in System Monitor that there is a phantom Discover process running. I cannot interact with it, nor can I see the Discover window on any desktop. Launching via command line gives nothing but a blank entry for approximately 5 minutes, before erroring with: `Failed to register name 'org.kde.discover' with DBUS - does this process have permission to use the name, and do no other processes own it already?` If I force-kill the phantom Discover process and try to launch Discover via command line, I instead get: ``` libs QList("/usr/lib/x86_64-linux-gnu/qt6/plugins", "/usr/bin") org.kde.plasma.libdiscover: OdrsReviewsBackend: Fetch ratings: true adding empty sources model QStandardItemModel(0x5650cae90080) ``` Then it hangs forever. Uninstalling/reinstalling Discover does not change anything; it acts the same after being freshly reinstalled. At system launch, I do get a notification from Discover: ``` Failed to update 1 package Error while installing package: trying to overwrite '/usr/share/dbus-1/services/org.kde.KSplash.service', which is also in package plasma-workspace 4 ``` This notification went away when I reinstalled plasma-workspace (`pkcon install plasma-workspace --allow-reinstall`), but Discover is still broken.
*** Bug 482071 has been marked as a duplicate of this bug. ***
There is something strange going on with the plugin loading. - plasma-discover --backends packagekit-backend works - plasma-discover --backends flatpak-backend works - plasma-discover --backends packagekit-backend,flatpak-backend doesn't Needs more investigation.
*** Bug 482046 has been marked as a duplicate of this bug. ***
(In reply to Harald Sitter from comment #4) > There is something strange going on with the plugin loading. > > - plasma-discover --backends packagekit-backend works > - plasma-discover --backends flatpak-backend works > - plasma-discover --backends packagekit-backend,flatpak-backend doesn't > > Needs more investigation. Can confirm this works for me. This is the output in the console, not sure if this is relevant for anyone: ``` jay@Navua-Neon:~$ plasma-discover --backends packagekit-backend org.kde.plasma.libdiscover: OdrsReviewsBackend: Fetch ratings: false adding empty sources model QStandardItemModel(0x557cc3851b40) qt.qml.typeresolution.cycle: Cyclic dependency detected between "qrc:/qt/qml/org/kde/desktop/private/TextFieldContextMenu.qml" and "qrc:/qt/qml/org/kde/desktop/MenuItem.qml" qrc:/qt/qml/org/kde/discover/qml/DiscoverWindow.qml:330:5: QML OverlaySheet: Binding loop detected for property "implicitHeight" qrc:/qt/qml/org/kde/discover/qml/BrowsingPage.qml:17:1: QML BrowsingPage: Created graphical object was not placed in the graphics scene. PackageKitBackend: No distro component found for "org.kde.neon.neon" AppStreamIntegration: No distro component found for "org.kde.neon.neon" qrc:/qt/qml/org/kde/discover/qml/UpdatesPage.qml:10:1: QML UpdatesPage: Created graphical object was not placed in the graphics scene. qrc:/qt/qml/org/kde/discover/qml/UpdatesPage.qml:39:5: QML OverlaySheet: Binding loop detected for property "y" ``` No distro component found for "org.kde.neon.neon" _feels_ suspicious to me but I don't know enough about the underlying systems here to know if that's normal behavior or not.
(In reply to Harald Sitter from comment #4) > There is something strange going on with the plugin loading. > > - plasma-discover --backends packagekit-backend works > - plasma-discover --backends flatpak-backend works > - plasma-discover --backends packagekit-backend,flatpak-backend doesn't > > Needs more investigation. Does not seem to do much in my case - same error, though I might have a different issue ... After update Dr Konqi seems to be having troubles with Discover as well. Background service seems to be doing fine, this looks like something GUI-related to me. vos@ether:~$ plasma-discover --backends packagekit-backend org.kde.plasma.libdiscover: OdrsReviewsBackend: Fetch ratings: true adding empty sources model QStandardItemModel(0x559a6c40c200) ASSERT: "isSorted(cats)" in file ./libdiscover/Category/Category.cpp, line 240 KCrash: Application 'plasma-discover' crashing... crashRecursionCounter = 2 KCrash: Application Name = plasma-discover path = /usr/bin pid = 8188 KCrash: Arguments: /usr/bin/plasma-discover --backends packagekit-backend KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi QSocketNotifier: Invalid socket 6 and type 'Read', disabling... QSocketNotifier: Invalid socket 19 and type 'Read', disabling... org.kde.drkonqi: Mapping found despite product information being provided by the application. Consider removing the mapping entry "plasma-discover" kf5idletime_wayland: This plugin does not support polling idle time
That's a different issue, not sure we have a bug report about it but I've definitely seen crash reports with this failed assert.
(In reply to Quinn Brown from comment #1) > (In reply to bmhieserich from comment #0) > > SUMMARY > > *** > > NOTE: If you are reporting a crash, please try to attach a backtrace with > > debug symbols. > > See > > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > > How_to_create_useful_crash_reports > > *** > > After fixing the other issues with the upgrade to Plasma 6 on KDE Neon > > through the terminal, Discover will not launch via attempting to launch > > through any method (launcher, krunner, terminal, etc). An instance of the > > application shows as running in the System Monitor, but there is no window > > or other visible sign that an instance of Discover is running. > > > > STEPS TO REPRODUCE > > 1. Attempt to launch Discover by any means (click on launcher, run > > "plasma-discover" in terminal, launch from krunner, etc) > > 2. Wait for Discover to finish launching to find no window opens > > 3. Open System Monitor to notice that it shows Discover as running > > > > OBSERVED RESULT > > Discover fails to provide any usable interface to do anything with. > > > > EXPECTED RESULT > > Discover launches and is usable. > > > > SOFTWARE/OS VERSIONS > > Linux/KDE Plasma: KDE Neon 6.0 > > (available in About System) > > KDE Plasma Version: 6.0.0 > > KDE Frameworks Version: 6.0.0 > > Qt Version: 6.6.2 > > > > ADDITIONAL INFORMATION > > I had the same situation myself. In addition to what they said, I had an > update notifier from Discover in my systray that worked, but I couldn't > launch the app from it. I have the same issue!
I also have the same issue where the 'Discover Notifier' runs, stating I have updates without 'Discover' operating. Without 'Discover' functioning properly, it looks as though no updates are capable of easily being installed. Therefore, besides 'pkcon' and 'Discover', a third method for determining/obtaining necessary updates, such as a web-based solution that is not dependent on 'Discover', may need to be considered - if not already available....
*** Bug 482303 has been marked as a duplicate of this bug. ***
I had something really weird happen: my surface was running for a day or 2 a sleep, I turn it on and I forget that Discover is broken. I click the updates available systray icon, Discover magically opens. I update my system and restart and now it won't open again? It's so odd.
I believe there is a race condition between flatpak and packagekit init where they can end up deadlocking each other inside plugin loading code. Or more specifically the flatpak backend tries to g_module load libsoup while appstream inside the packagekit backend tries to lazy g_module load GIO plugins. The packagekit thread loading appstream loading gio plugins trying to get a lock thread #14, name = 'Thread (pooled)', stop reason = signal SIGSTOP frame #0: 0x00007ff929e912c0 libc.so.6`__GI___lll_lock_wait at futex-internal.h:146:13 frame #1: 0x00007ff929e912aa libc.so.6`__GI___lll_lock_wait(futex=0x00007ff92d5aea48, private=0) at lowlevellock.c:49:7 frame #2: 0x00007ff929e9805d libc.so.6`___pthread_mutex_lock at pthread_mutex_lock.c:48:5 frame #3: 0x00007ff929e98046 libc.so.6`___pthread_mutex_lock(mutex=0x00007ff92d5aea48) at pthread_mutex_lock.c:128:7 frame #4: 0x00007ff92d5822ef ld-linux-x86-64.so.2`_dl_open(file="/usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so", mode=-2147483647, caller_dlopen=0x00007ff928a41b2c, nsid=-2, argc=3, argv=<unavailable>, env=0x00007ffebcebfcd8) at dl-open.c:830:3 frame #5: 0x00007ff929e9063c libc.so.6`dlopen_doit(a=0x00007ff8f97f9200) at dlopen.c:56:15 frame #6: 0x00007ff929f74a98 libc.so.6`__GI__dl_catch_exception(exception=0x00007ff8f97f9160, operate=<unavailable>, args=<unavailable>) at dl-error-skeleton.c:208:8 frame #7: 0x00007ff929f74b63 libc.so.6`__GI__dl_catch_error(objname=0x00007ff8f97f91b8, errstring=0x00007ff8f97f91c0, mallocedp=0x00007ff8f97f91b7, operate=<unavailable>, args=<unavailable>) at dl-error-skeleton.c:227:19 frame #8: 0x00007ff929e9012e libc.so.6`_dlerror_run(operate=<unavailable>, args=<unavailable>) at dlerror.c:138:17 frame #9: 0x00007ff929e906c8 libc.so.6`___dlopen [inlined] dlopen_implementation(dl_caller=<unavailable>, mode=<unavailable>, file=<unavailable>) at dlopen.c:71:10 frame #10: 0x00007ff929e906a7 libc.so.6`___dlopen(file=<unavailable>, mode=<unavailable>) at dlopen.c:81:12 frame #11: 0x00007ff928a41b2c libgmodule-2.0.so.0`g_module_open_full + 444 frame #12: 0x00007ff928e2e6db libgio-2.0.so.0`___lldb_unnamed_symbol4621 + 91 frame #13: 0x00007ff928fc926b libgobject-2.0.so.0`g_type_module_use + 107 frame #14: 0x00007ff928ef64b6 libgio-2.0.so.0`___lldb_unnamed_symbol6867 + 86 frame #15: 0x00007ff928e2eff6 libgio-2.0.so.0`g_io_extension_point_get_extensions + 22 frame #16: 0x00007ff928e34f0a libgio-2.0.so.0`___lldb_unnamed_symbol4657 + 554 frame #17: 0x00007ff928e755dd libgio-2.0.so.0`g_vfs_get_default + 93 frame #18: 0x00007ff928e1b9f2 libgio-2.0.so.0`g_file_new_for_path + 18 frame #19: 0x00007ff9290506f3 libappstream.so.5`as_cache_remove_old_data_from_dir.isra.0(cache_dir="/home/me/.cache/appstream", cache=<unavailable>) at as-cache.c:370:9 frame #20: 0x00007ff92901cba4 libappstream.so.5`as_cache_prune_data at as-cache.c:457:2 frame #21: 0x00007ff929051bc3 libappstream.so.5`as_pool_load_internal.constprop.0(pool=0x000055dc9f01d200, include_user_data=1, force_cache_refresh=0, caches_updated=0x0000000000000000, error=0x00007ff8f97f9548, cancellable=<unavailable>) at as-pool.c:1629:2 frame #22: 0x00007ff92a5d18de libAppStreamQt.so.3`AppStream::Pool::load() + 62 frame #23: 0x00007ff8f8306645 packagekit-backend.so`loadAppStream(appdata=0x000055dc9f028cc0) at PackageKitBackend.cpp:300:29 frame #24: 0x00007ff8f8318170 packagekit-backend.so`bool std::__invoke_impl<bool, bool (*&)(AppStream::Pool*), AppStream::Pool*&>((null)=__invoke_other @ 0x00007ff8f97f9628, __f=0x00007ff8f97f96a0, __args=0x00007ff8f97f9698) at invoke.h:61:14 frame #25: 0x00007ff8f831813d packagekit-backend.so`std::__invoke_result<bool (*&)(AppStream::Pool*), AppStream::Pool*&>::type std::__invoke<bool (*&)(AppStream::Pool*), AppStream::Pool*&>(__fn=0x00007ff8f97f96a0, __args=0x00007ff8f97f9698) at invoke.h:96:14 frame #26: 0x00007ff8f831810d packagekit-backend.so`std::invoke_result<bool (*&)(AppStream::Pool*), AppStream::Pool*&>::type std::invoke<bool (*&)(AppStream::Pool*), AppStream::Pool*&>(__fn=0x00007ff8f97f96a0, __args=0x00007ff8f97f9698) at functional:110:14 frame #27: 0x00007ff8f83180e1 packagekit-backend.so`QtConcurrent::StoredFunctionCall<bool (*)(AppStream::Pool*), AppStream::Pool*>::runFunctor(this=0x00007ff8f97f97a0, function=(packagekit-backend.so`loadAppStream(AppStream::Pool*) at PackageKitBackend.cpp:299), args=0x000055dc9f028cc0)::'lambda'(bool (*)(AppStream::Pool*), AppStream::Pool*)::operator()(bool (*)(AppStream::Pool*), AppStream::Pool*) const at qtconcurrentstoredfunctioncall.h:116:20 frame #28: 0x00007ff8f83180ab packagekit-backend.so`bool std::__invoke_impl<bool, QtConcurrent::StoredFunctionCall<bool (*)(AppStream::Pool*), AppStream::Pool*>::runFunctor()::'lambda'(bool (*)(AppStream::Pool*), AppStream::Pool*) const&, bool (*)(AppStream::Pool*), AppStream::Pool*>((null)=__invoke_other @ 0x00007ff8f97f96d8, __f=0x00007ff8f97f97a0, __args=0x000055dc9f01aa88, __args=0x000055dc9f01aa80) at invoke.h:61:14 frame #29: 0x00007ff8f8318035 packagekit-backend.so`std::__invoke_result<QtConcurrent::StoredFunctionCall<bool (*)(AppStream::Pool*), AppStream::Pool*>::runFunctor()::'lambda'(bool (*)(AppStream::Pool*), AppStream::Pool*) const&, bool (*)(AppStream::Pool*), AppStream::Pool*>::type std::__invoke<QtConcurrent::StoredFunctionCall<bool (*)(AppStream::Pool*), AppStream::Pool*>::runFunctor()::'lambda'(bool (*)(AppStream::Pool*), AppStream::Pool*) const&, bool (*)(AppStream::Pool*), AppStream::Pool*>(__fn=0x00007ff8f97f97a0, __args=0x000055dc9f01aa88, __args=0x000055dc9f01aa80) at invoke.h:96:14 frame #30: 0x00007ff8f8317ffe packagekit-backend.so`decltype(auto) std::__apply_impl<QtConcurrent::StoredFunctionCall<bool (*)(AppStream::Pool*), AppStream::Pool*>::runFunctor()::'lambda'(bool (*)(AppStream::Pool*), AppStream::Pool*) const&, std::tuple<bool (*)(AppStream::Pool*), AppStream::Pool*>, 0ul, 1ul>(__f=0x00007ff8f97f97a0, __t=0x000055dc9f01aa80, (null)=std::index_sequence<0UL, 1UL> @ 0x00007ff8f97f9748) at tuple:1852:14 frame #31: 0x00007ff8f8317f7d packagekit-backend.so`decltype(auto) std::apply<QtConcurrent::StoredFunctionCall<bool (*)(AppStream::Pool*), AppStream::Pool*>::runFunctor()::'lambda'(bool (*)(AppStream::Pool*), AppStream::Pool*) const&, std::tuple<bool (*)(AppStream::Pool*), AppStream::Pool*>>(__f=0x00007ff8f97f97a0, __t=0x000055dc9f01aa80) at tuple:1863:14 frame #32: 0x00007ff8f831718a packagekit-backend.so`QtConcurrent::StoredFunctionCall<bool (*)(AppStream::Pool*), AppStream::Pool*>::runFunctor(this=0x000055dc9f01aa60) at qtconcurrentstoredfunctioncall.h:122:27 frame #33: 0x00007ff8f83170f6 packagekit-backend.so`QtConcurrent::RunFunctionTaskBase<bool>::run(this=0x000055dc9f01aa60) at qtconcurrentrunbase.h:83:13 frame #34: 0x00007ff92a966d7d libQt6Core.so.6`___lldb_unnamed_symbol10932 + 541 frame #35: 0x00007ff92a96036d libQt6Core.so.6`___lldb_unnamed_symbol10875 + 333 frame #36: 0x00007ff929e94ac3 libc.so.6`start_thread(arg=<unavailable>) at pthread_create.c:442:8 frame #37: 0x00007ff929f26850 libc.so.6`__clone3 at clone3.S:81 the gui thread loading flatpak also trying to get a lock. (while presumably holding a dl level lock?) * thread #1, name = 'plasma-discover', stop reason = signal SIGSTOP * frame #0: 0x00007ff929e912c0 libc.so.6`__GI___lll_lock_wait at futex-internal.h:146:13 frame #1: 0x00007ff929e912aa libc.so.6`__GI___lll_lock_wait(futex=0x00007ff8d00068a0, private=0) at lowlevellock.c:49:7 frame #2: 0x00007ff929e9805d libc.so.6`___pthread_mutex_lock at pthread_mutex_lock.c:48:5 frame #3: 0x00007ff929e98046 libc.so.6`___pthread_mutex_lock(mutex=0x00007ff8d00068a0) at pthread_mutex_lock.c:128:7 frame #4: 0x00007ff928a41a07 libgmodule-2.0.so.0`g_module_open_full + 151 frame #5: 0x00007ff8d465f3a5 libsoup-2.4.so.1`___lldb_unnamed_symbol1978 + 53 frame #6: 0x00007ff92d57a47e ld-linux-x86-64.so.2`call_init(l=<unavailable>, argc=3, argv=0x00007ffebcebfcb8, env=0x00007ffebcebfcd8) at dl-init.c:70:3 frame #7: 0x00007ff92d57a568 ld-linux-x86-64.so.2`_dl_init [inlined] call_init(env=0x00007ffebcebfcd8, argv=0x00007ffebcebfcb8, argc=3, l=<unavailable>) at dl-init.c:33:6 frame #8: 0x00007ff92d57a53b ld-linux-x86-64.so.2`_dl_init(main_map=0x000055dc9f02c130, argc=3, argv=0x00007ffebcebfcb8, env=0x00007ffebcebfcd8) at dl-init.c:117:5 frame #9: 0x00007ff929f74af5 libc.so.6`__GI__dl_catch_exception(exception=<unavailable>, operate=<unavailable>, args=<unavailable>) at dl-error-skeleton.c:182:7 frame #10: 0x00007ff92d581ff6 ld-linux-x86-64.so.2`dl_open_worker at dl-open.c:808:5 frame #11: 0x00007ff92d581fc8 ld-linux-x86-64.so.2`dl_open_worker(a=0x00007ffebcebdc10) at dl-open.c:771:1 frame #12: 0x00007ff929f74a98 libc.so.6`__GI__dl_catch_exception(exception=0x00007ffebcebdbf0, operate=0x000000000000df60, args=0x00007ffebcebdc10) at dl-error-skeleton.c:208:8 frame #13: 0x00007ff92d58234e ld-linux-x86-64.so.2`_dl_open(file=<unavailable>, mode=-2147479551, caller_dlopen=0x00007ff92a909cb0, nsid=-2, argc=3, argv=<unavailable>, env=0x00007ffebcebfcd8) at dl-open.c:883:17 frame #14: 0x00007ff929e9063c libc.so.6`dlopen_doit(a=0x00007ffebcebde80) at dlopen.c:56:15 frame #15: 0x00007ff929f74a98 libc.so.6`__GI__dl_catch_exception(exception=0x00007ffebcebdde0, operate=<unavailable>, args=<unavailable>) at dl-error-skeleton.c:208:8 frame #16: 0x00007ff929f74b63 libc.so.6`__GI__dl_catch_error(objname=0x00007ffebcebde38, errstring=0x00007ffebcebde40, mallocedp=0x00007ffebcebde37, operate=<unavailable>, args=<unavailable>) at dl-error-skeleton.c:227:19 frame #17: 0x00007ff929e9012e libc.so.6`_dlerror_run(operate=<unavailable>, args=<unavailable>) at dlerror.c:138:17 frame #18: 0x00007ff929e906c8 libc.so.6`___dlopen [inlined] dlopen_implementation(dl_caller=<unavailable>, mode=<unavailable>, file=<unavailable>) at dlopen.c:71:10 frame #19: 0x00007ff929e906a7 libc.so.6`___dlopen(file=<unavailable>, mode=<unavailable>) at dlopen.c:81:12 frame #20: 0x00007ff92a909cb0 libQt6Core.so.6`___lldb_unnamed_symbol9792 + 1248 frame #21: 0x00007ff92a90b0c6 libQt6Core.so.6`___lldb_unnamed_symbol9793 + 54 frame #22: 0x00007ff92a9ef985 libQt6Core.so.6`QPluginLoader::load() + 117 frame #23: 0x00007ff92a9ef9f9 libQt6Core.so.6`QPluginLoader::instance() + 25 frame #24: 0x00007ff92d3a687f libDiscoverCommon.so`DiscoverBackendsFactory::backendForFile(this=0x00007ffebcebe530, libname=0x000055dc9efc2828, name=0x000055dc9efc2828) const at DiscoverBackendsFactory.cpp:53:98 frame #25: 0x00007ff92d3a67c2 libDiscoverCommon.so`DiscoverBackendsFactory::backend(this=0x00007ffebcebe530, name=0x000055dc9efc2828) const at DiscoverBackendsFactory.cpp:44:16 frame #26: 0x00007ff92d3a7c2b libDiscoverCommon.so`DiscoverBackendsFactory::allBackends() const::$_0::operator()(this=0x00007ffebcebe3f0, name=0x000055dc9efc2828) const at DiscoverBackendsFactory.cpp:96:16 frame #27: 0x00007ff92d3a728f libDiscoverCommon.so`QList<AbstractResourcesBackend*> kTransform<QList<AbstractResourcesBackend*>, QList<QString>, DiscoverBackendsFactory::allBackends() const::$_0>(input=0x00007ffebcebe478, op=(this = 0x00007ffebcebe530)) at utils.h:53:16 frame #28: 0x00007ff92d3a710c libDiscoverCommon.so`DiscoverBackendsFactory::allBackends(this=0x00007ffebcebe530) const at DiscoverBackendsFactory.cpp:95:16 frame #29: 0x00007ff92d361660 libDiscoverCommon.so`ResourcesModel::registerAllBackends(this=0x000055dc9f1672b0) at ResourcesModel.cpp:241:29 frame #30: 0x00007ff92d360b81 libDiscoverCommon.so`ResourcesModel::init(this=0x000055dc9f1672b0, load=true) at ResourcesModel.cpp:98:9 frame #31: 0x00007ff92d360a75 libDiscoverCommon.so`ResourcesModel::global() at ResourcesModel.cpp:39:17 frame #32: 0x00007ff92d33b6ea libDiscoverCommon.so`CategoryModel::CategoryModel(this=0x000055dc9f0176e0, parent=0x0000000000000000) at CategoryModel.cpp:22:13 frame #33: 0x00007ff92d33bac0 libDiscoverCommon.so`CategoryModel::global() at CategoryModel.cpp:39:24 frame #34: 0x000055dc9cb77a3c plasma-discover`DiscoverDeclarativePlugin::registerTypes(this=0x000055dc9f010890, (null)="org.kde.discover") at DiscoverDeclarativePlugin.cpp:63:77 frame #35: 0x000055dc9cb4b824 plasma-discover`DiscoverObject::DiscoverObject(this=0x000055dc9ebbde30, initialProperties=0x00007ffebcebf328) at DiscoverObject.cpp:145:13 frame #36: 0x000055dc9cb44bfd plasma-discover`main(argc=3, argv=0x00007ffebcebfcb8) at main.cpp:173:34 frame #37: 0x00007ff929e29d90 libc.so.6`__libc_start_call_main(main=(plasma-discover`main at main.cpp:96), argc=3, argv=0x00007ffebcebfcb8) at libc_start_call_main.h:58:16 frame #38: 0x00007ff929e29e40 libc.so.6`__libc_start_main_impl(main=(plasma-discover`main at main.cpp:96), argc=3, argv=0x00007ffebcebfcb8, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007ffebcebfca8) at libc-start.c:392:3 frame #39: 0x000055dc9cb32bd5 plasma-discover`_start + 37
A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/766
plasma-discover failed to create drawable libs QList("/usr/lib/x86_64-linux-gnu/qt6/plugins", "/usr/bin") org.kde.plasma.libdiscover: OdrsReviewsBackend: Fetch ratings: true adding empty sources model QStandardItemModel(0x55e077b453f0) ASSERT: "isSorted(cats)" in file ./libdiscover/Category/Category.cpp, line 240 KCrash: Application 'plasma-discover' crashing... crashRecursionCounter = 2 KCrash: Application Name = plasma-discover path = /usr/bin pid = 12465 KCrash: Arguments: /usr/bin/plasma-discover KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi org.kde.drkonqi: Mapping found despite product information being provided by the application. Consider removing the mapping entry "plasma-discover" void ReportInterface::maybePickUpPostbox() 29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. Unable to start Dr. Konqi org.kde.drkonqi: Could not open sentry payload file "/tmp/drkonqi-nYLRiB/sentry_payload.json" void ReportInterface::maybePickUpPostbox() kinfo failed to create drawable Operating System: KDE neon 6.0 KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.5.0-21-lowlatency (64-bit) Graphics Platform: X11 Processors: 2 × Intel® Core™2 Duo CPU E4700 @ 2.60GHz Memory: 2.8 ГіБ of RAM Graphics Processor: llvmpipe
Created attachment 167002 [details] Discover opening while a terminal shows uptime
I had the same thing where discover would open after sleeping again, so I took a screenshot this time. After I restarted from the update this time I clicked on Discover again in the app menu and it opened. I closed it and clicked the update notifier and nothing would open again. I tried to kill the processes in System Monitor and nothing worked.
Git commit a1ea1062ee5b5681bb2c5b4e462ad9ac8b66defe by Harald Sitter. Committed on 18/03/2024 at 20:46. Pushed by sitter into branch 'Plasma/6.0'. packagekitbackend: de-thread the appstream loading hotfix the threading causes a race condition in module loading where GIO (appstream,packagekit) and libsoup (flatpak) try to load modules at the same time and get stuck on each other. disable threading to temporarily fix this for 6.0 needs addressing in 6.1 in a more reasonable way. perhaps move all plugin loading into a threadpool with size 1? or run the first appstream loading on the gui thread? or have appstream provide an init function? M +1 -0 libdiscover/backends/PackageKitBackend/PackageKitBackend.cpp https://invent.kde.org/plasma/discover/-/commit/a1ea1062ee5b5681bb2c5b4e462ad9ac8b66defe
Created attachment 167493 [details] Discover crash The app also goes BOOM for me. Here is the data being shown in KsystemLog before being erased. Also below video shows the issue. https://youtu.be/rmLTl6oYdDc
System info: Operating System: openSUSE Tumbleweed 20240315 KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.7.9-1-default (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 5825U with Radeon Graphics Memory: 62.1 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: HP Product Name: HP ProBook 455 15.6 inch G9 Notebook PC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/801
Git commit bdee5a19e435cacd53480a65d63a01932da1b639 by Harald Sitter. Committed on 26/03/2024 at 22:14. Pushed by sitter into branch 'master'. flatpak, packagekit: fix threaded deadlock in dlopen/gmodule the use of threads caused a deadlock between appstream's lazy initialization code running in one thread and flatpak's init running in another. the two would try to dlopen further libraries of which some will gmodule load plugins. the problem appears to then be that the threads can end up locked between two mutexes (the dlopen one and the gmodule one). instead use a safer albeit less efficient means of init: queue the init into the event loop. this uses a two stage queue which looks a bit funny but seems to have much the same performance characteristics as the threading did. M +26 -16 libdiscover/backends/FlatpakBackend/FlatpakBackend.cpp M +17 -7 libdiscover/backends/PackageKitBackend/PackageKitBackend.cpp https://invent.kde.org/plasma/discover/-/commit/bdee5a19e435cacd53480a65d63a01932da1b639
Git commit 9fd1c5fe01b48ee381ad3fcd621ca932cf3f1502 by Harald Sitter. Committed on 26/03/2024 at 22:45. Pushed by sitter into branch 'Plasma/6.0'. flatpak, packagekit: fix threaded deadlock in dlopen/gmodule the use of threads caused a deadlock between appstream's lazy initialization code running in one thread and flatpak's init running in another. the two would try to dlopen further libraries of which some will gmodule load plugins. the problem appears to then be that the threads can end up locked between two mutexes (the dlopen one and the gmodule one). instead use a safer albeit less efficient means of init: queue the init into the event loop. this uses a two stage queue which looks a bit funny but seems to have much the same performance characteristics as the threading did. (cherry picked from commit bdee5a19e435cacd53480a65d63a01932da1b639) M +26 -16 libdiscover/backends/FlatpakBackend/FlatpakBackend.cpp M +17 -8 libdiscover/backends/PackageKitBackend/PackageKitBackend.cpp https://invent.kde.org/plasma/discover/-/commit/9fd1c5fe01b48ee381ad3fcd621ca932cf3f1502
Can confirm this is now fixed on my end! Thank you!
Hi, this bug seems to affect plasma 5.27.11 as well, with snap ( possibly flatpak ) I know this is for neon and plasma 6, do I need to open a new bug? https://bugs.launchpad.net/ubuntu/+source/plasma-discover/+bug/2063353
If it's already fixed but not backported to 5.27, no need for a new bug report. Just backport the commit I think.
This issue just started happening to me in plasma 6.1.3 on fedora 40. The app launches fine the first time, but then gets stuck as a ghost process in the background. Manually killing the ghost process lets me reopen discover, but I have to do this every time. This seems to be a result of the same (or a very similar) problem with the backends, since running > plasma-discover --backends packagekit-backend or > plasma-discover --backends flatpak-backend makes the app behave and exit normally. Fedora 40 Plasma ver. 6.1.3 KDE frameworks ver. 6.4.0 QT ver. 6.7.2 Kernel ver. 6.9.12-200.fc40.x86_64 (This is my first bug report here, apologies if I messed up any etiquette)
What you're seeing is very likely a different issue; please open a new bug report for it. Thanks.
*** Bug 492128 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #26) > If it's already fixed but not backported to 5.27, no need for a new bug > report. Just backport the commit I think. Dear Nate, I am experiencing an issue compatible with the symptoms described in this bug in Kubuntu 24.04 with KDE Plasma 5.27.11. It's probably the same bug. Do you know if there is any timeline to backport the fix to KDE 5.27? Thanks.
"failure to launch" is a symptom that can have ten thousand root causes; there's no evidence that this is your issue. It's probably something else. Unfortunately 5.27 is pretty much abandoned by developers; the Plasma 6 transition has eaten up any resources there might have been to investigate, develop, or backport fixes for Plasma 5.27. Any support will need to come from the distro developers at this point. And I would strongly recommend upgrading to Kubuntu 24.10 when it's released, which will include Plasma 6.
(In reply to Nate Graham from comment #31) > "failure to launch" is a symptom that can have ten thousand root causes; > there's no evidence that this is your issue. It's probably something else. > > Unfortunately 5.27 is pretty much abandoned by developers; the Plasma 6 > transition has eaten up any resources there might have been to investigate, > develop, or backport fixes for Plasma 5.27. Any support will need to come > from the distro developers at this point. And I would strongly recommend > upgrading to Kubuntu 24.10 when it's released, which will include Plasma 6. Dear Nate, Thanks for the quick reply and sorry for not being specific enough in my previous messge. I will try to be more precise this time: When I was referring to the same symptoms I was not only referring to the failure to launch, I am also experiencing the other symptoms described by others here, namely: * The issue doe snot appear if I load only one backend or a selection and also the order of backend loading seems to play a role. * According to the fix this seems ultimately caused by a race condition, this is coherent with the fact that running it with strace solves the issue. (i.e. `strace plasma-discover` works fine) * When runing with gdb and examining in detail the hang it seems to be waiting for mutex lock: ``` (gdb) backtrace #0 futex_wait (private=0, expected=2, futex_word=0x5555559cb850) at ../sysdeps/nptl/futex-internal.h:146 #1 __GI___lll_lock_wait (futex=futex@entry=0x5555559cb850, private=0) at ./nptl/lowlevellock.c:49 #2 0x00007ffff52a0147 in lll_mutex_lock_optimized (mutex=0x5555559cb850) at ./nptl/pthread_mutex_lock.c:48 #3 ___pthread_mutex_lock (mutex=0x5555559cb850) at ./nptl/pthread_mutex_lock.c:128 #4 0x00007ffff456d64d in g_rec_mutex_lock (mutex=mutex@entry=0x7ffff5418070 <g_module_global_lock>) at ../../../glib/gthread-posix.c:397 #5 0x00007ffff5414a05 in g_module_open_full (file_name=file_name@entry=0x0, flags=flags@entry=0, error=error@entry=0x0) at ../../../gmodule/gmodule.c:478 #6 0x00007ffff54154bb in g_module_open (file_name=file_name@entry=0x0, flags=flags@entry=0) at ../../../gmodule/gmodule.c:708 #7 0x00007fffdf283668 in soup2_is_loaded () at ../libsoup/soup-init.c:26 #8 soup_init () at ../libsoup/soup-init.c:54 #9 soup_init_ctor () at ../libsoup/soup-init.c:96 #10 0x00007ffff7fca71f in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffd898, env=env@entry=0x7fffffffd8a8) at ./elf/dl-init.c:74 #11 0x00007ffff7fca824 in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=<optimized out>) at ./elf/dl-init.c:120 #12 _dl_init (main_map=0x5555559d08c0, argc=1, argv=0x7fffffffd898, env=0x7fffffffd8a8) at ./elf/dl-init.c:121 #13 0x00007ffff7fc65b2 in __GI__dl_catch_exception (exception=exception@entry=0x0, operate=operate@entry=0x7ffff7fd1cc0 <call_dl_init>, args=args@entry=0x7fffffffc6c0) at ./elf/dl-catch.c:211 #14 0x00007ffff7fd1d7c in dl_open_worker (a=0x7fffffffc870) at ./elf/dl-open.c:829 #15 dl_open_worker (a=a@entry=0x7fffffffc870) at ./elf/dl-open.c:792 #16 0x00007ffff7fc651c in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffc850, operate=operate@entry=0x7ffff7fd1ce0 <dl_open_worker>, args=args@entry=0x7fffffffc870) at ./elf/dl-catch.c:237 #17 0x00007ffff7fd2164 in _dl_open (file=0x55555595c828 "/usr/lib/x86_64-linux-gnu/qt5/plugins/discover/snap-backend.so", mode=<optimized out>, caller_dlopen=0x7ffff5cd3a67 <QLibraryPrivate::load_sys()+1415>, nsid=<optimized out>, argc=1, argv=0x7fffffffd898, env=0x7fffffffd8a8) at ./elf/dl-open.c:905 #18 0x00007ffff5298194 in dlopen_doit (a=a@entry=0x7fffffffcb20) at ./dlfcn/dlopen.c:56 #19 0x00007ffff7fc651c in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffca60, operate=0x7ffff5298130 <dlopen_doit>, args=0x7fffffffcb20) at ./elf/dl-catch.c:237 #20 0x00007ffff7fc6669 in _dl_catch_error (objname=0x7fffffffcac8, errstring=0x7fffffffcad0, mallocedp=0x7fffffffcac7, operate=<optimized out>, args=<optimized out>) at ./elf/dl-catch.c:256 #21 0x00007ffff5297c73 in _dlerror_run (operate=operate@entry=0x7ffff5298130 <dlopen_doit>, args=args@entry=0x7fffffffcb20) at ./dlfcn/dlerror.c:138 #22 0x00007ffff529824f in dlopen_implementation (dl_caller=<optimized out>, mode=<optimized out>, file=<optimized out>) at ./dlfcn/dlopen.c:71 #23 ___dlopen (file=<optimized out>, mode=<optimized out>) at ./dlfcn/dlopen.c:81 #24 0x00007ffff5cd3a67 in QLibraryPrivate::load_sys (this=0x5555559cc670) at plugin/qlibrary_unix.cpp:238 #25 0x00007ffff5cccfa5 in QLibraryPrivate::load (this=this@entry=0x5555559cc670) at plugin/qlibrary.cpp:584 #26 0x00007ffff5ccd57b in QLibraryPrivate::loadPlugin (this=0x5555559cc670) at plugin/qlibrary.cpp:641 #27 0x00007ffff5cbdd36 in QPluginLoader::load (this=0x5555559cb4f0) at plugin/qpluginloader.cpp:238 #28 QPluginLoader::load (this=0x5555559cb4f0) at plugin/qpluginloader.cpp:229 #29 0x00007ffff5cbde81 in QPluginLoader::instance (this=this@entry=0x5555559cb4f0) at plugin/qpluginloader.cpp:197 #30 0x00007ffff7ebc334 in DiscoverBackendsFactory::backendForFile (this=this@entry=0x7fffffffd00f, libname=..., name=...) at /usr/src/plasma-discover-5.27.11-0ubuntu2/libdiscover/DiscoverBackendsFactory.cpp:53 #31 0x00007ffff7ebc7d3 in DiscoverBackendsFactory::backend (this=this@entry=0x7fffffffd00f, name=...) at /usr/src/plasma-discover-5.27.11-0ubuntu2/libdiscover/DiscoverBackendsFactory.cpp:44 #32 0x00007ffff7ebc93a in operator() (name=..., __closure=<synthetic pointer>) at /usr/src/plasma-discover-5.27.11-0ubuntu2/libdiscover/DiscoverBackendsFactory.cpp:95 #33 kTransform<QVector<AbstractResourcesBackend*>, QStringList, DiscoverBackendsFactory::allBackends() const::<lambda(const QString&)> > (op=..., input=...) at /usr/src/plasma-discover-5.27.11-0ubuntu2/libdiscover/utils.h:53 #34 DiscoverBackendsFactory::allBackends (this=0x7fffffffd00f) at /usr/src/plasma-discover-5.27.11-0ubuntu2/libdiscover/DiscoverBackendsFactory.cpp:96 --Type <RET> for more, q to quit, c to continue without paging-- ``` Finally, I won't be upgrading to Kubuntu 24.10 as I like to stick with LTS editions. So I will try to forward the issue to the distribution maintainers and see if there is any luck. Best regards