Dolphin randomly uses 100% on just one CPU core. I'm not entirely sure what causes this, but i think it could be related to baloo search. Reproducible: Sometimes Steps to Reproduce: 1. start dolphin 2. use dolphin for some time 3. leave dolphin open and do something else 4. dolphin's CPU usage goes up to 100% Actual Results: High CPU usage when idle, most noticable through laptop fan Expected Results: Normal CPU usage strace reports a lot of: stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2237, ...}) = 0 lines per second
Thanks for the bug report! In order to understand what keeps the CPU busy, we need a backtrace that shows a snaphot of the program execution. Please see https://community.kde.org/Dolphin/FAQ/Freeze for details. Thanks for your help!
I'm running dolphin now for approximately 2 days through GDB. The bug didn't occur yet, but I also noticed that dolphin has problems connecting with plasmashell if I run it like this. Notifications aren't getting through correctly, the notification for deleting a file is spinning infinitely and the notification itself is only showing a progress bar.
Thanks for the feedback. You can also attach gdb to a Dolphin process which is already running if it's easier to reproduce the problem with a Dolphin instance that is not running in gdb. If you observe that Dolphin has high CPU usage, you can attach gdb to it with gdb attach $(pidof dolphin) (if there is just one Dolphin window open). Alternatively, find out the process ID of the Dolphin process and then run "gdb <pid>". Thanks.
Created attachment 92719 [details] Dolphin GDB backtrace
Created attachment 92720 [details] Dolphin strace Dolphin emits a lot of stat("/etc/localtime", ...) syscalls don't know if this is normal behaviour or even related to this issue
I just noticed, the detailed view was active while dolphin ran at 100% CPU. As soon as I switched to some other view everything turned back to normal. The date column is displayed in the detailed view.
Thanks for the backtrace! According to the backtrace, the time-related things are caused by QMimeDatabase, which is a new class in Qt5 that the KIO framework uses to determine mime types (in KDE SC 4.x times, KIO/kdelibs hat its own code for that). I don't know why Qt deals with the time when determining mime types - maybe it wants to find out if the shared-mime-info on the system has changed since the last mime type determination, such that it can decide if it can use some cached data or not, I don't know. Some more questions: 1. Am I assuming correctly that you used "Sort by Type" when you observed the slowness? 2. How many files are there in the folder where you see the problem? 3. Is the problem reproducible if you visit that folder again? 4. Do you also see the high CPU load if you visit the folder in the "Open file" dialog of, e.g., KWrite and use "Sort by Type"? 5. Are you sure that the high CPU load is not visible in Icons View? If you use "Sort by Type" there, I don't see a reason why the behaviour should be different. Thanks for your help! I also see a high CPU load when visiting a folder with a huge number of items (100,000) and using "Sort by Type", by the way, but the backtraces that I get are different (in QXmlStreamReader code that is called by QMimeType::comment). Maybe Qt's mime type handling is inefficient, but then this has to be fixed in the Qt library.
Yes, I'm sorting by type (I also display them in groups, but I think that does not matter) The high CPU load seems to appear randomly, but I think it happens most of the time when I open a directory like /usr/bin (~3600 files) or /usr/lib (~3800 files) When I leave the directory that caused the high load, it goes back to normal. It does not happen again when I change back into this directory. I still need to investigate the file dialog etc.
I've got a similar problem (kubuntu 4.14.6, dolphin 14.12.3) I use the detail view with expandable folders and also sort by type. The instance is used for a long time, so it is reopened by the session manager after reboot and stays alive when suspended. When I expand folders with many pdf files in them and open one, the cpu usage for one core is at 100% until I go back one step back in the dolphin history (collapsing is not enough). of cause, it's not reproducible all the time :/
Created attachment 93743 [details] 100% cpu backtrace reproduces as in comment 9 after the dump, i let the instance run on and it did not use 100% cpu anymore.
I have to correct myself, i did not manage to continue the run. the instance is dead so the last line in #10 is invalid.
i have some more findings. The problem appears directly after collapsing the tree that was open for a while. The process in question is the main process. The window stays responsive and you may work within while at 100%. (see another backtrace and htop screen shot)
Created attachment 93744 [details] another backtrace belonging to the htop screen shot
Created attachment 93745 [details] see another backtrace
There is a patch in Qt now which will hopefully fix this issue in future Qt releases: https://codereview.qt-project.org/#/c/122247/ @stefan: Your backtraces are not related to the problem in this bug report, which only affects the KF5/Qt5-based version of Dolphin. From the backtrace, I cannot see at first sight what the problem might be. If you can still reproduce the problem when you upgrade to Dolphin 15.08 or later, please file a new bug report about the problem. Thanks!
Closing as upstream for now. Please reopen if you are still affected with Qt >= 5.5