SUMMARY On startup plasmashell tries to parse an ELF executable as a config file, resulting in 3 minutes of CPU burn, and unresponsive desktop, and 4 million errors logged in journalctl. STEPS TO REPRODUCE 1. Download the VSCode tarball from https://update.code.visualstudio.com/1.85.2/linux-x64/stable 2. Untar it into a local folder under home. 2. Login to plasmashell Note: When I tried to repro this by copying the file somewhere like in the steps above, it did not occur again. I'll try to repro again when I get more time to experiment. OBSERVED RESULT Desktop displays but doesn't respond to mouse or keyboard for 3 minutes. Syslog is spammed with parse errors like this: plasmashell[17552]: kf.config.core: "KConfigIni: In file /home/phord/ude_installations/.VSCode-linux-x64.2024-05-03T16:13:56.8ff70376.ude/code, line 40238: " Invalid entry (missing '=') SOFTWARE/OS VERSIONS Operating System: KDE neon 6.0 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.5.0-35-generic (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-10610U CPU @ 1.80GHz Memory: 15.2 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics Manufacturer: LENOVO Product Name: 20UCS4TR00 System Version: ThinkPad X1 Yoga Gen 5 ADDITIONAL INFORMATION Possibly related to Bug 465517. In this case the file is not named "*.desktop", but it is an appimage which did contain a file named ".desktop", it seems. It is Electron instance (VSCode). $ file "/home/phord/ude_installations/.VSCode-linux-x64.2024-05-03T16:13:56.8ff70376.ude/code" /home/phord/ude_installations/.VSCode-linux-x64.2024-05-03T16:13:56.8ff70376.ude/code: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=8568a1e8a49c9f715f0c0ec32106257b915b9851, not stripped $ gio info "/home/phord/ude_installations/.VSCode-linux-x64.2024-05-03T16:13:56.8ff70376.ude/code" | grep content standard::content-type: application/x-executable standard::fast-content-type: application/octet-stream $ mimetype "/home/phord/ude_installations/.VSCode-linux-x64.2024-05-03T16:13:56.8ff70376.ude/code" /home/phord/ude_installations/.VSCode-linux-x64.2024-05-03T16:13:56.8ff70376.ude/code: application/x-executable $ kmimetypefinder5 "/home/phord/ude_installations/.VSCode-linux-x64.2024-05-03T16:13:56.8ff70376.ude/code" application/x-executable
On later tests, I found that baloo_file_extractor was the busy process consuming CPU while the desktop failed to start. The file it was scanning was /home/$USER/ude_installations/.VSCode-linux-x64.*/code. It was not named ".desktop" or anything similar. I tried to repro by copying the the same binary to /home/$USER/test/, but I didn't see the same result. Removing the file from where it was solved my startup problem for now.
I cannot reproduce this issue with--coincidentally--exactly the same hardware, but Fedora 40 as the distro, and all KDE software built from source on top of it.
(In reply to Phil Hord from comment #0) > ... parse errors like this: > plasmashell[17552]: kf.config.core: "KConfigIni: In file /home/phord/ude_installations/.VSCode-linux-x64.2024-05-03T16:13:56.8ff70376.ude/code, line 40238: " Invalid entry (missing '=') A "dot file/folder"? I've downloaded and unpacked the https://update.code.visualstudio.com/1.85.2/linux-x64/stable - just "as is". The system is not set up as a dev system, just plain and simple vanilla... I have the 'code' file as ~/ude_installations/VScode-linux-x64/code, it's certainly big and kmimetypefinder has it as application/x-executable. No problems with indexing as far as I can see, balooshow just gives the metadata (filename and MIME type) I'm guessing something else is happening, "kf.config.core" errors don't sound like Baloo. If for some reason Baloo thinks that the "code" file is indexable, it would certainly work hard to index the 100Mbyte... Checked on Neon User...
> A "dot file/folder"? Yes, good point. I hadn't considered that significant before. > No problems with indexing as far as I can see, balooshow just gives the metadata (filename and MIME type) > I'm guessing something else is happening, "kf.config.core" errors don't sound like Baloo. I believe I blamed baloo because `ps aux` in another tty told me the busy process. But I don't have those logs now. I'll try to repro again.
I managed to repro this, but it doesn't seem as severe as before. I recreated it by running the same installer I used before (an internal product at my work). And this time I noticed the installer created a .desktop file symlinked to the "code" binary. So, I think that explains the whole thing. Maybe this is a Plasma issue, then? Something parsing config files should be ready to give up sooner, I think. I probably misblamed baloo for this earlier. I think I found baloo with `top`, which isn't fair because baloo opportunistically uses idle CPU to do work. Maybe the fact that it was the "baloo_file_extractor" running and that the suspect file was a packed file made me feel more confident. But I thought I also pegged it with `lsof`. Now, I'm not so sure. > Tasks: 291 total, 2 running, 289 sleeping, 0 stopped, 0 zombie > %Cpu(s): 1.8 us, 4.5 sy, 8.1 ni, 82.6 id, 3.1 wa, 0.0 hi, 0.0 si, 0.0 st > MiB Mem : 15610.4 total, 10130.0 free, 2198.7 used, 3281.7 buff/cache > MiB Swap: 17190.1 total, 16977.3 free, 212.8 used. 11913.3 avail Mem > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 2861 phord 39 19 256.3g 218140 80640 D 74.4 1.4 0:35.52 baloo_file_extr > 3132 phord 20 0 2625400 212064 135040 S 10.6 1.3 0:05.97 plasma-systemmo > 2018 phord -2 0 2391456 300600 235632 S 5.6 1.9 0:03.73 kwin_wayland > 10 root 20 0 0 0 0 I 2.0 0.0 0:02.39 kworker/u16:0-kcryptd/252:1 > 314 root 20 0 0 0 0 I 2.0 0.0 0:01.69 kworker/u16:5-kcryptd/252:1 > 3221 root 20 0 0 0 0 I 2.0 0.0 0:00.91 kworker/u16:11-kcryptd/252:1 > 3233 root 20 0 0 0 0 I 2.0 0.0 0:00.28 kworker/u16:12-kcryptd/252:1 > 3244 phord 20 0 1856156 269508 241868 S 2.0 1.7 0:00.59 konsole > 190 root 20 0 0 0 0 I 1.3 0.0 0:01.36 kworker/u16:4-kcryptd/252:1 > 276 root 20 0 0 0 0 S 1.3 0.0 0:00.73 dmcrypt_write/252:1 > 315 root 20 0 0 0 0 I 1.3 0.0 0:01.36 kworker/u16:6-kcryptd/252:1 > 319 root 20 0 0 0 0 I 1.3 0.0 0:01.59 kworker/u16:8-kcryptd/252:1 > 340 root 20 0 0 0 0 R 1.3 0.0 0:01.88 kworker/u16:9-kcryptd/252:1 > 41 root 20 0 0 0 0 S 1.0 0.0 0:00.12 ksoftirqd/4 > 367 root 19 -1 109456 61568 60416 S 1.0 0.4 0:02.12 systemd-journal > 3183 phord 20 0 233524 7168 6784 S 1.0 0.0 0:00.69 ksgrd_network_h > 2461 phord 20 0 1132.4g 242896 173120 S 0.7 1.5 0:08.37 slack > 3305 phord 20 0 10848 4352 3328 R 0.7 0.0 0:00.03 top
(In reply to Phil Hord from comment #5) > ... the installer created a .desktop file symlinked to the "code" binary ... That certainly has potential :-) Baloo won't index dot files/folders unless you configure it to. It's probably configured to ignore such hidden folders by default. What it does when it hits a symlink (with a .desktop extension) referencing a file in a hidden folder; that's worth a test. Baloo *normally* avoids following symlinks when indexing - but you can do things you shouldn't and sidestep that restriction. The groundrule is that Baloo relies on a one-to-one match between filename and an internal "DocId" that it generates for each file - where the DocId is derived from the FileSystem ID (nowadays) and the inode and symlinks can mess that up.... You might need to turn on debugging and see if it gives you anything useful https://bugs.kde.org/show_bug.cgi?id=487916#c8
(In reply to tagwerk19 from comment #6) > (In reply to Phil Hord from comment #5) > > ... the installer created a .desktop file symlinked to the "code" binary ... > That certainly has potential :-) If the installer was *really* creating a symlink with a .desktop extension, that's a bit "unusual" and might easily cause a wild rumpus... > ... What it does when it hits a symlink (with a .desktop extension) referencing a file in a > hidden folder; that's worth a test ... I tried various things but didn't see Baloo following the symlink... I tried with a "normal" (minimal) .desktop file, the results were slightly confused by Baloo indexing the content of the .desktop file (and that contains the name of the target). If you search for the name of the target file, you'll find the whatever.desktop. No hint that Baloo would/might index the target... Did you find out more?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!