Discover stops responding on open/searching apps/updating. STEPS TO REPRODUCE 1. Open Discover. OBSERVED RESULT Discover stops responding about 10 seconds. This reoccurs every time you search for something or click on an app. EXPECTED RESULT Discover works smoothly. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 40 KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5600H with Radeon Graphics Memory: 15.5 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3060 Laptop GPU/PCIe/SSE2 A similar issue happens for the Plasma Widget browser, making it nearly impossible to install widgets.
Maybe the same thing as that other recent KNS network issue, Harald?
When discover stops responding run `killall -ABRT plasma-discover` That should bring up the crash dialog. On the developer information page you should be able to retrieve a backtrace. Alternatively if you know how to use gdb you can also run it through that and just interrupt when the lockup happens. In any case also see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Backtraces
Hi. Sorry for the delay. I will paste the output below. Before, however, I want to note here that this bug may also apply to the application launcher (when searching apps) as it takes a few seconds to load. The launcher however does not give a "not responding" indication, nor does it happen consistently like Discover (it seems like it happens the first time I use it after boot/ a period of time of not using it). It's also maybe important to mention that it worked fine on Fedora 40 (implicitly KDE Plasma 6) before it ended like this. This goes for both Discover and the Application Launcher. Output: ``` [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/bin/plasma-discover'. Program terminated with signal SIGABRT, Aborted. #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0; [Current thread is 1 (Thread 0x7fc8be1bab00 (LWP 6321))] KCRASH_INFO_MESSAGE: Content of s_kcrashErrorMessage: std::unique_ptr<char []> = {get() = <optimized out>} Cannot QML trace cores :( ```
Created attachment 173007 [details] Backtrace Discover Discover Backtrace
(In reply to ryuuramaru from comment #3) > Hi. > > Sorry for the delay. > > I will paste the output below. > > Before, however, I want to note here that this bug may also apply to the > application launcher (when searching apps) as it takes a few seconds to > load. The launcher however does not give a "not responding" indication, nor > does it happen consistently like Discover (it seems like it happens the > first time I use it after boot/ a period of time of not using it). > > It's also maybe important to mention that it worked fine on Fedora 40 > (implicitly KDE Plasma 6) before it ended like this. This goes for both > Discover and the Application Launcher. > > Output: > ``` > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Core was generated by `/usr/bin/plasma-discover'. > Program terminated with signal SIGABRT, Aborted. > #0 __pthread_kill_implementation (threadid=<optimized out>, > signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 > 44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO > (ret) : 0; > [Current thread is 1 (Thread 0x7fc8be1bab00 (LWP 6321))] > KCRASH_INFO_MESSAGE: Content of s_kcrashErrorMessage: std::unique_ptr<char > []> = {get() = <optimized out>} > > Cannot QML trace cores :( > ``` Sorry, pasted the wrong thing. The full trace is in the attachments. I cannot paste it here as it is too large
Do you have a proxy configured if so which specific settings?
Created attachment 173009 [details] Config file for DNS proxy
(In reply to Harald Sitter from comment #6) > Do you have a proxy configured if so which specific settings? I set my DNS server for my internet connection to localhost, where I run dnscrypt for DNS over HTTPS. I attached its full config. Please let me know if you need anything else.
Right, I guess that is the problem. under the hood Qt uses libproxy to detect proxies and that tries to do proxy auto discovery by accessing http://wpad/wpad.dat but that appears to not return in any sensible time frame so libproxy gets stuck and by extension anything that does network IO through Qt does. Naturally that includes discover and plasma. You'll have to fix your setup so wpad immediately resolves to nothing I guess. Alternatively you could figure out why libproxy wants to do wpad and disable that feature.
(In reply to Harald Sitter from comment #9) > Right, I guess that is the problem. > > under the hood Qt uses libproxy to detect proxies and that tries to do proxy > auto discovery by accessing http://wpad/wpad.dat but that appears to not > return in any sensible time frame so libproxy gets stuck and by extension > anything that does network IO through Qt does. Naturally that includes > discover and plasma. You'll have to fix your setup so wpad immediately > resolves to nothing I guess. Alternatively you could figure out why libproxy > wants to do wpad and disable that feature. Wow, yeah, setting to No Proxy from the network settings GUI instantly solved Discover and everything else I can think of. Though, dnscrypt runs locally so even with that setting, as long as localhost is set as my DNS server, I still have DNS over HTTPS, from what I can tell doing dnsleaktest.com