(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.