SUMMARY When I open a Vault in Dolphin and leave it open for a while, often it eventually starts consuming a lot of CPU (21 - 22% overall on a 4-core) without me doing anything with it. It never does that outside of Vaults. STEPS TO REPRODUCE 1. Open a Vault in Dolphin 2. Open a file in the Vault 3. Leave Dolphin open OBSERVED RESULT Eventually DOplhin can start consuming a lot of CPU EXPECTED RESULT Dolphin doesn't consume CPU while user does nothing SOFTWARE/OS VERSIONS Operating System: KDE neon 5.15 KDE Plasma Version: 5.15.4 KDE Frameworks Version: 5.57.0 Qt Version: 5.12.0 Kernel Version: 4.15.0-47-generic OS Type: 64-bit Processors: 4 × Intel® Core™ i5-7200U CPU @ 2.50GHz Memory: 7,5 GiB of RAM ADDITIONAL INFORMATION
Yes, I have seen this as well. It's very reproducible.
Ineresting. What happens if it is a manually created cryfs/encfs drive?
I can confirm the bug for a manually created EncFS directory.
In that case, seems Dolphinny rather than Vaulty.
I temporarily switched to Konquerer and it shows the same behavior. What do both file managers have in common?
Konqueror uses Dolphin for the file management views.
that means it's a Dolphin bug, right?
Yep.
It seems this bug is not limited to encrypted folders anymore. When I open my (unencrypted) home directory, Dolphin immediately starts consuming 100% of one CPU. The only error I see upon running it from command line is 'kf5.kio.core: "Could not enter folder tags:/."'
Another interesting observation (the encrypted EncFS folder is mounted to a folder in the home directory): First opening the home folder in Dolphin, then mounting the EncFS folder => everything OK. First mounting the EncFS folder, then opening the home folder in Dolphin => 100% load.
(In reply to Johannes from comment #9) > It seems this bug is not limited to encrypted folders anymore. When I open > my (unencrypted) home directory, Dolphin immediately starts consuming 100% > of one CPU. The only error I see upon running it from command line is > 'kf5.kio.core: "Could not enter folder tags:/."' That's an unrelated issue, and a new bug should be filed for it.
How's that unrelated? If an encrypted subfolder is mounted, Dolphin behaves as showing that folder, if it's not mounted, everything's fine.
I now even saw a Dolphin process with 100% CPU consumption without having any instance of Dolphin running.
Which version of cryfs are you using? Does it happen with cryfs 0.9.11?
EncFS 1.9.5 here
anyone has an idea how to fix/control that bug?
A workaround may be be to switch to a different backend, such as cryfs.
For me the problem exists only if "Preview" are enabled for current directory. Thus possible workaround is disabling preview for affected directories.
(In reply to Adrián Chaves (Gallaecio) from comment #14) > Which version of cryfs are you using? Does it happen with cryfs 0.9.11? Ich have cryfs 0.9.9. Is there an easy way to get 0.9.11 on neon to test it?
(In reply to Enrico Ronconi from comment #18) > For me the problem exists only if "Preview" are enabled for current > directory. > Thus possible workaround is disabling preview for affected directories. Same here, it seems like the preview is the problem.
I can say that at the beggining when vault was introduced, no lag when browsing a folder of the vault (i use cryfs), and i could have thumbnails and previews without any issue, and since some time ago (some months) i can't even have previews or thumbnails in dolphin (gwenview does create thumbnails) and browsing, even with preview disabled, is very laggy
*** Bug 421042 has been marked as a duplicate of this bug. ***
Same here: - encfs 1.9.5 mounted by command line or KencFS (same result) - OS: Kubuntu 20.04 64bit - Kernel 5.4.0-37-generic - Plasma: 5.18.5 - KDE Framework: 5.86.0 - Qt: 5.12.8 Different steps to reproduce: - Open a file from encrypted directory with Dolphin - Save that file with the application it was opened with => CPU-load of one core goes to 100% and stays there until Dolphin is closed - closing the file or the application doesn't help - opening the file directly with the application makes no trouble I'm using encfs and Kubuntu since 12.04 (only the LTS-Versions; encfs might have come with 14.04) and I never observed this problem. 20.04 was a fresh install and no KDE-settings have been copied from the 18.04-homedir. All previews in Dolphin are disabled (they just confuse me, I need my filetype symbols).
FWIW I'm unable to reproduce this with the git master version of everything KDE. But it's possible that an update to encfs itself fixed this. Can anyone on Arch or openSUSE Tumbleweed with latest KDE stuff (built from source or using unstable repos) confirm?
What I tried since the last post: I found out that on an identically installation (not a clone) on my notebook with a copy of the encfs-folders the problem did not exist. On the PC with the dolphin-encfs-problem ... - I created a new user: no solution - I created a new encfs-folder: no solution - I removed all non-standard mount options from the drives: no solution - I copied the complete system from the notebook to the PC (and made it boot again): no solution!!! - I installed SpaceFM (small, few dependencies, but I like dolphin much more): anything working correct Additionally I found out ... - that the problem only exists with programs creating tmp/bak/swp-files like kate/kwrite and libreoffice - that the cpu-load normalizes when changing to another directory, but it goes back to 100% on one core when one goes back to the directory of the files - that the cpu-load normalizes when completely deleting the file - that the cpu-load normalizes after putting the file to the waste bin and restoring it The problem is reproducible with the live usb drive with Kubuntu 20.04.0. Trying live usb drives with "neon-user-20200702-1117" and "openSUSE-Leap-15.2-KDE-Live-x86_64-Build31.105-Media" act as expected. This means that it is a Kubuntu 20.04.0 problem which appears only on some computers. Hence this are the data of my computers: PC with the problem: i7-3930K, X79 Express chipset, 64 GB RAM, AMD RX580 GPU Notebook: i5-4200U, ??? chipset, 12 GB RAM, integrated Intel GPU used, additional GeForce GT 750M not used but driver installed Finally this probably means that I'm in the wrong forum as it is Kubuntu-specific. Sorry!
Thanks for the detailed investigation! That's very helpful. I don't think it's Kubuntu-specific though; I was experiencing it in the past on openSUSE Tumbleweed, and I'm still using that OS but now it's gone for me.
I contacted Henning an during a testing session we discovered that the issue still kan be triggered wit an new Kubuntu 20.04.1 live-Session, if you have an older CPU in your system. No special requirement and 100% reproducible on my lenovo x230 thinkpad wit Intel Core i7 3XXX CPU. a) Start live-Session of Kubuntu b) create a encfs (all the tools are already installed - no network connection neccessary) encfs /path/to/encrypted_folder /path/to/unecrypted_folder (you can choose the paranoia settings) and set a password c) Open the unecrypted folder in dolphin an create a libre-office file. d) leave the dolphin folder-view open an type some garbage in the file - the contend doesn't matter e) Save the file in libre office f) Dolphin now uses 100% CPU of a core In Kubuntu 20.04.1 you can press F5 or change the folder in dolphin to another one to get thing back to normal. I'm currently testing some VM environments with cpu-flags if i can recreate the same behavior on more modern CPUs.
I changed some of the bug-details so that they showing the vversion on wich the bug can be easily be repoduced. I tried some cpu-flags wit kvm on my tumbleweed machine. While tumbleweed itself does not show teh bug due tuo newer qt and framwork versions, i can tell that a virtual machine based on kvm ist preatty sufficient to show the bug. i tried EPYC-IBPB, Westmere, Westmere (without CPU flaw mitigations), Sandy Bridge and qemu64 as cpu settings and they all show the same behavior. So nearly everybody should be able to witness this behavior. I will try to test it on different real systems as well..
Assuming that the Dolphin+EncFS-problem is a result of the CPU/CPU-flags in conjunction with the compiler/compiler-flags I also did some further investigations. Out of habit I used "Oracle VM Virtualbox" with host-extensions installed for USB support. (No guest-extensions installed by me; Virtualbox 6.1) The results: i5-4200U host: Kubuntu 20.04.1 works fine with Dolphin+EncFS VM on that i5-4200U host: Kubuntu 20.04.1 shows the Dolphin+EncFS-problem i7-3930K host: Kubuntu 20.04.1 shows the Dolphin+EncFS-problem Therefore I took a look at the CPU-flags by comparing the output of /proc/cpuinfo. If I can attach the LO-calc-file, I will do so. But from my point of view, these flags are the most interesting: Flag only on the two systems where the problem appears (VM@4200U and 3930K): x2apic Flags missing on the two systems where the problem appears but available on the working system (4200U): bmi1, bmi2, cpuid_fault, ept_ad, erms, f16c, fma, sdbg, smep, tsc_adjust. There are a lot flags missing only in the VM and some others are missing on the 3930K only. Hence I listed all flags that are common on the systems where the Dolphin+EncFS-problem appears. Since I don't really know much about CPU- or compiler-flags, I also played around with CPU-microcode and patches on the native 3930K. Booting without any microcode loaded to the CPU by Kubuntu does not solve the Dolphin+EncFS-problem just as adding "mitigations=off" to grub. Does anyone have an old ISO-image of Neon with Plasma 5.18? Testing Dolphin+EncFS there inside a VM would be quite interesting! P.S.: A Kubuntu 20.04.1-VM on the i5-4200U running Win10 as host OS also shows the Dolphin+EncFS-problem.
Created attachment 131021 [details] CPU-flags compared between i7-3930K, i5-4200U and Virtualbox VM on i5-4200U as announced in comment 29
WORKAROUND FOUND First, sorry for the confusion with processor flags and so on. My 'solution' is extremely easier but means that there is really a bug in Dolphin under Kubuntu 20.04.1. Jacob proposed to create a new user on the installation on the notebook where the problem does not appear. Very good idea, because the problem appeared with the new user. Hence, everbody can reproduce the problem with any Kubuntu 20.04 and it is the standard when using EncFS with Dolphin. I really compared the settings of Dolphin and the KDE settings and it took me a lot of time. More time was wasted comparing CPU flags and investigating VM behaviour. But since the problem appeared with the new user on the notebook, it had to be a setting. I would have searched there if I wasn't sure I had adjusted all settings correctly. Finally the problem does not appear, when one disables the file preview in Dolphin. This setting is not in the menu settings > setup Dolphin but really easy to find in the menu view (or whatever it is callend in English; third menu when showing the menu bar, entry no. 8). If you enable to see hidden files and the preview, Dolphin goes to 100% on one core as soon as you begin typing something into an existing textfile in Kate. With only preview enabled, the problem appears when saving and disappears after updating the view - as discribed in the past. Disabling the prewiew, anything works fine on the EncFS folder regardless of showing hidden files or not. Thus, I do not have a problem anymore, but I hope that the Kubuntu team will fix this bug. Perhaps this also helps Thomas. The setting if the preview is disabled is stored in the hidden file ~/.local/share/dolphin/view_properties/global/.directory in the section [Dolphin] by the line PreviewsShown=false. Thanks - Henning
*** Bug 436699 has been marked as a duplicate of this bug. ***