Bug 493404 - Fedora Asahi Remix - Discover will occasionally fail to start
Summary: Fedora Asahi Remix - Discover will occasionally fail to start
Status: RESOLVED UPSTREAM
Alias: None
Product: Discover
Classification: Applications
Component: discover (other bugs)
Version First Reported In: 6.1.4
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-09-20 14:41 UTC by Talya
Modified: 2024-10-16 15:16 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
Discover failing to start when opening from task manager or application launcher (168.45 KB, video/webm)
2024-09-20 14:41 UTC, Talya
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Talya 2024-09-20 14:41:41 UTC
Created attachment 173911 [details]
Discover failing to start when opening from task manager or application launcher

SUMMARY


STEPS TO REPRODUCE
1. Boot into Fedora Asahi Remix
2. Have updates pending download (you can see the "Updates available" icon
3. Try opening Discover in any method (clicking on the "Updates available" icon, clicking on Discover from the task manager, opening Discover from the Application Launcher, doesn't matter)

This method is not able to consistently reproduce the bug. The bug doesn't seem to happen consistently, and I'm not certain of the pattern that causes it.

OBSERVED RESULT
Clicking on the "Updates available" icon will do nothing.

Clicking on Discover in the task manager or trying to open Discover from the Application Launcher will result in some loading, then nothing.

EXPECTED RESULT
Discover starts as expected.

SOFTWARE/OS VERSIONS

Operating System: Fedora Linux Asahi Remix 40
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2

ADDITIONAL INFORMATION
A simple reboot seems to always solve the problem. However, the bug has returned multiple times, always with the same behaviour, so it's clear this is not a permanent solution.
Comment 1 Nate Graham 2024-09-20 15:49:39 UTC
When this happens, can you open a terminal window and run `ps -e | grep discover` to see if it's secretly already running and blocking a new instance being opened?

If not, then while you've got that terminal window open, please try to launch it using `plasma-discover` and paste the text that appears there. Thanks!
Comment 2 Talya 2024-09-20 16:05:44 UTC
I actually already ran `plasma-discover` already and it didn't help. however:
turns out it *was* running in the background, just not visible in any workspace. killing the process and running it from the terminal worked, and now it opens normally.

I do wonder how did it happen though. Because it does seem to occasionally happen without a discernable pattern. my only guess is that it's whenever there's >100 packages to update, but the only reason I'm thinking so is there were this time when I managed to open it.
Comment 3 Nate Graham 2024-09-20 17:06:20 UTC
I had a feeling it had failed to quit and was secretly still running in the background. This kind of problem is unfortunately unpleasant to debug. The next time it happens, could you attach to it with `gdb` and get a trace of what it's doing? Let me know if you need more detailed instructions than that.
Comment 4 Talya 2024-09-20 17:17:03 UTC
I would appreciate more detailed instructions :)
will let you know when I have the details.
Comment 5 Nate Graham 2024-09-24 14:53:09 UTC
No problem! In a terminal window:
1. Type "gdb attach `pidof plasma-discover` " and hit return
2. If it says "--Type <RET> for more, q to quit, c to continue without paging--c", hit "c"
3. Wait for it to finish downloading things if necessary
4. Once you see "(gdb)", type "bt" and hit return

Copy and paste what it shows into a comment here.
Comment 6 Talya 2024-09-24 21:11:04 UTC
this time slightly different behaviour, discover failed to load all updates so I closed to try again and it didn't open.
here's the debug info:

#0  0x0000fffee53a6254 in __GI___poll (fds=0xaaab3a0b3fe0, nfds=<optimized out>, 
    timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:41
#1  0x0000fffee41c56f8 [PAC] in g_main_context_poll_unlocked (priority=2147483647, 
    context=0xfffec8000f00, timeout=<optimized out>, fds=0xaaab3a0b3fe0, n_fds=9)
    at ../glib/gmain.c:4521
#2  g_main_context_iterate_unlocked.isra.0 (context=context@entry=0xfffec8000f00, 
    block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at ../glib/gmain.c:4212
#3  0x0000fffee4162084 [PAC] in g_main_context_iteration (context=0xfffec8000f00, 
    may_block=1) at ../glib/gmain.c:4282
#4  0x0000fffee5b82638 [PAC] in QEventDispatcherGlib::processEvents (
    this=0xaaab38fe17a0, flags=...)
    at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.aarch64/src/corelib/kernel/qeventdispatcher_glib.cpp:394
#5  0x0000fffee588f674 [PAC] in QEventLoop::exec (this=this@entry=0xffffe3d784c0, 
    flags=flags@entry=...)
    at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.aarch64/src/corelib/global/qflags.h:34
#6  0x0000fffee588ac1c [PAC] in QCoreApplication::exec ()
    at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.aarch64/src/corelib/global/qflags.h:74
#7  0x0000fffee5fc4830 [PAC] in QGuiApplication::exec ()
    at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.aarch64/src/gui/kernel/qguiapplication.cpp:1926
#8  0x0000fffee7cde9b8 in QApplication::exec ()
    at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.aarch64/src/widgets/kernel/qapplication.cpp:2555
#9  0x0000aaab33103b58 in main (argc=<optimized out>, argv=<optimized out>)
    at /usr/src/debug/plasma-discover-6.1.5-1.fc40.aarch64/discover/main.cpp:219
Comment 7 Talya 2024-09-27 12:39:48 UTC
I think I can consistently reproduce the issue now.
1. boot and have discover auto-open
2. have discover try to fetch updates
3. close discover mid-fetching
4. discover will now continue running in the background and clicking on its icon will do nothing.
Comment 8 Bug Janitor Service 2024-10-12 03:47:55 UTC
๐Ÿ›๐Ÿงน โš ๏ธ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!
Comment 9 Nate Graham 2024-10-16 15:16:59 UTC
This appears to be a QtWayland regression; see https://bugzilla.redhat.com/show_bug.cgi?id=2318535