Created attachment 185601 [details] The Output Of `time strace -Ttr plasma-discover` # SUMMARY Apparently randomly, I (and other users, including my brother, per https://discuss.kde.org/t/why-cant-i-open-discover/39560/5?u=rokejulianlockhart) become unable to invoke Discover, until we invoke `qdbus-qt6 org.kde.Shutdown /Shutdown org.kde.Shutdown.logoutAndReboot` (`org.kde.Shutdown.logout` might also work, but I've yet to confirm, due to how rarely this reproduces). # STEPS TO REPRODUCE Invoke `plasma-discover` (from `$Env:PATH`, in `bash`). # OBSERVED RESULT It closes with an `EAGAIN` of "Resource temporarily unavailable", but requires an inordinate amount of time to: > ~~~ > real 5m8.252s > user 0m0.307s > sys 0m0.273s > ~~~ Most notable is: > ~~~ > 13:15:37 (+ 0.000029) futex(0x55bcc7b568d8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY) = 0 <299.662141> > 13:20:37 (+ 299.662324) futex(0x55bcc7b56890, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000085> > ~~~ I've seen this reach 300 s, but that's a mere difference of 1 s. # EXPECTED RESULT It should invoke. # SOFTWARE/OS VERSIONS > ~~~ > Operating System: Fedora Linux 42 > KDE Plasma Version: 6.4.5 > KDE Frameworks Version: 6.18.0 > Qt Version: 6.9.2 > Kernel Version: 6.16.9-200.fc42.x86_64 (64-bit) > Graphics Platform: Wayland > ~~~ The hardware likely doesn't matter, due to the amount of hardware that this has occurred on.
Created attachment 185602 [details] The `perf.data`, And Its `.perfparser` Counterpart, Created By `perf record --debuginfod --call-graph dwarf plasma-discover` Luckily, this is easy to accurately profile, because it closes itself. However, per https://discussion.fedoraproject.org/t/why-does-perf-lack-debuginfod-capabilities/167812, the perf file *may* lack symbols (although doesn't appear to).
When this happens, is there already a `plasma-discover` process running in the background, with no window?
(In reply to Nate Graham from comment #2) > When this happens, is there already a `plasma-discover` process running in > the background, with no window? I believe so, because I did see the system tray icon (whose context menu refused to invoke)! I've neglected to check System Monitor when it reproduces, so that's the best I can provide until it reproduces next. Tangentially, when this occurs, the Task Manager icon is always stuck at approximately 10 % progress. At least, that's what its green underlay indicates.
Based on the symptoms, I'm declaring this a duplicate of Bug 507217. *** This bug has been marked as a duplicate of bug 507217 ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/1194
Un-duplicating since this is still happening. Bug 507217 was fixed in 6.6.0 with an update to the Snap backend, and this bug doesn't involve snaps. The same errors as in the original report are seen in the latest strace in the other bug.
I have, since, ascertained that Discover consistently fails to invoke, after the first time that it is invoked, solely when the System Tray plasmoid's `DiscoverNotifier` entrant is visible. If `DiscoverNotifier` is quitted, Discover immediately becomes possible to invoke again. Unfortunately, no updates are available for me, now. Consequently, I have not been able to trace Discover whilst this problem reproduces, to ensure that it equivalates what I have described in this report.
Created attachment 194170 [details] Konsole Output, Which Demonstrates That `DiscoverNotifier` Being Active Is A Cause Of Invocation Failure At https://youtu.be/5KnstzWPTs4 is a screencast, which confirms that what I last described certainly prevents it invoking. However, it does not wait for 300 s, like this bug very explicitly describes. Is it a separate problem? I have attached the depicted logs, too, if they are worth investigating.