| Summary: | Fedora Asahi Remix - Discover will occasionally fail to start | ||
|---|---|---|---|
| Product: | [Applications] Discover | Reporter: | Talya <myjunkmailbox2801> |
| Component: | discover | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | aleixpol, nate |
| Priority: | NOR | ||
| Version First Reported In: | 6.1.4 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Discover failing to start when opening from task manager or application launcher | ||
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! 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. 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. I would appreciate more detailed instructions :) will let you know when I have the details. 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. 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
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. 🐛🧹 ⚠️ 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! This appears to be a QtWayland regression; see https://bugzilla.redhat.com/show_bug.cgi?id=2318535 |
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.