Created attachment 171919 [details] video of issue SUMMARY I thought for a while that my laptop had a serious issue, because I didn't consider the possibility that a simple application like Dolphin could be responsible. However it's 100% reproducible for me - at least right now. Opening Dolphin to an empty directory from Konsole results in momentary hangs. The specific hang might be happening in the KWin compositor - if I play a video in VLC on a loop it appears to intermittently hang along with everything else. Further debugging steps that might help isolate the issue would be appreciated. STEPS TO REPRODUCE 1. Close all Konsole windows and open a new session. 1. In Konsole, make a new directory "~/Downloads/empty". 2. Open it with Dolphin directly, i.e. "dolphin ~/Downloads/empty". (These steps are just intended to eliminate side effects. The directory I open doesn't seem to matter.) OBSERVED RESULT Visible hangs every second or two (see attached video). Using strace, Dolphin appears to be spamming a lot of syscalls. It seems to be polling continually for something - I see a lot of `poll` and `clock_gettime` calls. These go silent when Dolphin is in the background when it is launched normally, but they are continuous when I launch it from Konsole. I have seen the same issue before and I'm not sure if it always happened the same way (i.e. starting Dolphin from Konsole) or not. I don't think I *always* see the issue every time I start Dolphin from Konsole, but I'll double check this next time I reboot. EXPECTED RESULT No lag. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.9.10-arch1-1 (64-bit) Graphics Platform: Wayland I have Radeon graphics integrated into the laptop CPU. No Nvidia.
Hi Adam and everybody! I can reproduce Adan's symptoms on the plasma 6.x desktop environment on fedora 40. It seems they didn't happen when using xfce as a desktop environment. System: Host: telaviv1.shlomifish.org Kernel: 6.9.9-200.fc40.x86_64 arch: x86_64 bits: 64 Desktop: KDE Plasma v: 6.1.3 Distro: Fedora Linux 40 (Xfce) CPU: Info: dual core model: Intel Core i3-2100 bits: 64 type: MT MCP cache: L2: 512 KiB Speed (MHz): avg: 3093 min/max: 1600/3100 cores: 1: 3093 2: 3093 3: 3093 4: 3094 Graphics: Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics driver: i915 v: kernel Display: wayland server: X.Org v: 24.1.1 with: Xwayland v: 24.1.1 compositor: kwin_wayland driver: X: loaded: modesetting unloaded: fbdev,vesa dri: crocus gpu: i915 resolution: 1920x1080~60Hz API: OpenGL v: 3.3 vendor: intel mesa v: 24.1.4 renderer: Mesa Intel HD Graphics 2000 (SNB GT1) API: EGL Message: EGL data requires eglinfo. Check --recommends.
Heads' up : it indeed does not happen after I shutdown the computer (after misinterpreting plasma's UI) , turned it on, and logged-into X/xfce
I updated and rebooted, and continue to be able to reproduce the issue.
Okay, so I've further narrowed down the issue to a specific environment variable that triggers it. A shell started with a clean environment via `sudo -u $USER /bin/bash` didn't show the issue, but as soon as I add back the following environment variable from my real environment, it happens again. XDG_CONFIG_HOME=/home/$USER/.config/ dolphin . Vice versa, I also was able to work around the problem by starting Dolphin with a blank XDG_CONFIG_HOME variable in my normal environment. In addition, I was able to partially reproduce the issue on a different system that didn't exhibit the compositor hang by adding this environment variable. While the compositor does not clearly hang as it does on my system, I was able to reproduce the syscall spam issue. Without this specific environment variable, Dolphin issues no syscalls when its window is in the background. With it, activity from Dolphin is constant. It is very surprising to me that this can make a difference, because I would normally expect most programs to treat this directory as the configuration root by default anyway.
Apologies for the spam, but I've just noticed that removing the slash from the end of the path prevents the issue, which is truly bizarre. Issue: XDG_CONFIG_HOME=/home/$USER/.config/ No issue: XDG_CONFIG_HOME=/home/$USER/.config I've never seen this cause an issue in any other application, but it's 100% reproducible here, including the syscall issue. Would appreciate anyone else attempting to reproduce.
Created attachment 172018 [details] dolphin flamegraph A flamegraph seems really helpful here, although the issue is *not* CPU use (<20% of one core). Dolphin is spending almost all its CPU time in `KBuildSycoca::recreate` via KService::serviceByDesktopName -> Ksycoca::ensureCacheValid -> KSycocaPrivate::checkDatabase Looking at backtraces in gdb, it looks like we hit `DolphinMainWindow::updateOpenPreferredSearchToolAction` over and over again. There could be a loop here? https://invent.kde.org/system/dolphin/-/blob/master/src/dolphinmainwindow.cpp#L228 If this function is run whenever the sycoca database changes, but the function itself is capable of triggering a database refresh if KSycoca says the database is invalid (e.g. maybe because a bad string comparison using the file path with a trailing slash??), then it could potentially loop? Speculation on my part.
It looks like the check here is repeatedly failing: https://invent.kde.org/frameworks/kservice/-/blob/master/src/sycoca/ksycoca.cpp?ref_type=heads#L662 return extraFiles.keys() != files; I'm not sure how to inspect these QStringLists within gdb, but I wonder if this comparison could involve the kind of string comparison issue I speculated about above.
Okay after a bit more debugging I can say for sure this is a KService bug. In the check at https://invent.kde.org/frameworks/kservice/-/blob/master/src/sycoca/ksycoca.cpp?ref_type=heads#L662 return extraFiles.keys() != files; The left hand side is QList("/home/adam/.config/mimeapps.list", "/home/adam/.local/share/applications/mimeapps.list", "/usr/share/applications/kde-mimeapps.list") The right hand side is QList("/home/adam/.config//mimeapps.list", "/home/adam/.local/share/applications/mimeapps.list", "/usr/share/applications/kde-mimeapps.list") The lack of path normalization here means that KService thinks the sycoca database needs to be rebuilt every time an application asks. Dolphin hitting an endless loop here because of the `databaseChanged` signal should probably be prevented, but the underlying issue is with KService so I'm moving this bug there for more attention.
(In reply to Adam Fontenot from comment #7) > It looks like the check here is repeatedly failing: > https://invent.kde.org/frameworks/kservice/-/blob/master/src/sycoca/ksycoca. > cpp?ref_type=heads#L662 > > return extraFiles.keys() != files; > > I'm not sure how to inspect these QStringLists within gdb, but I wonder if > this comparison could involve the kind of string comparison issue I > speculated about above. Hi Adam! just for-the-record, this gdb script file may be helpful for this: https://github.com/shlomif/shlomif-computer-settings/blob/master/shlomif-settings/gdb/gdb/kde-devel-gdb.gdb .
I had a PR accepted that fixes the underlying issue in KService by normalizing user provided config paths. In theory this should mean that this problem won't arise again from this specific source, where KService thinks the database needs to be regenerated because it is looking at two different paths to the same config file. So I'm closing this issue. That said, I'm not really that satisfied with the outcome, but I don't know how to push it further. I think it's probably bad that Dolphin can trigger an endless loop (which involves continuous disk IO!), and that didn't get fixed here. (In reply to Shlomi Fish from comment #9) > Hi Adam! just for-the-record, this gdb script file may be helpful for this: > https://github.com/shlomif/shlomif-computer-settings/blob/master/shlomif- > settings/gdb/gdb/kde-devel-gdb.gdb . Thanks, I'll have a look at that for future debugging. KDevelop has some gdb scripts, but unfortunately many of the types (including QMap) don't seem to support Qt6. https://invent.kde.org/kdevelop/kdevelop/-/tree/master/plugins/gdb/printers