Bug 434125 - High CPU usage with "size of contents" option when trying to analyze "/proc" folder
Summary: High CPU usage with "size of contents" option when trying to analyze "/proc" ...
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: view-engine: details mode (show other bugs)
Version: 20.12.3
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-03-07 23:11 UTC by Yevhen Popok
Modified: 2023-01-09 15:22 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yevhen Popok 2021-03-07 23:11:18 UTC
SUMMARY
I had high CPU usage while "Dolphin" window was opened. Later I figured out that problem was with "size of contents" option which I manually turned on. And specifically with symlink "z:" which point to "/" in "$HOME/.wine/dosdevices/" folder. That symlink Wine creates by default during configuration.

STEPS TO REPRODUCE
1. Settings > Configure Dolphin > View Modes > Details. For "Folder size displays" select "Size of contents, up to 4 levels deep"
2. F4 to open terminal
3. Create symlink to "/proc" with command and "ln -s /proc test_size"


OBSERVED RESULT
Dolphin start eating up to 48% of CPU and at some point will show some strange value like "21,6 PiB"

EXPECTED RESULT
Probably Dolphin shouldn't inspect symlinks and /proc directory

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: KDE neon User Edition
KDE Plasma Version: 5.21
KDE Frameworks Version: 5.79
Qt Version: 5.15.2

ADDITIONAL INFORMATION
Comment 1 Méven Car 2021-04-27 07:10:54 UTC
FYI the folder size counting takes into account folder hiding, i.e with hidden folders hidden you wouldn't experience this issue.
Comment 2 Jérôme Borme 2021-05-24 00:03:05 UTC
Activating option "Size of contents, up to 10 levels deep", leads to 100% cpu usage in a seemingly infinite loop (can last hours). Some dirs also report a much overestimated size.

On one example, a dir (15 levels, 1045 dir, 41233 files, `du` size of 169 GiB) is reported as 512.2 TiB.

Selecting a lower number of levels (2-3) does not trigger the problem (size is underestimated, as expected).

The tree might contain circular symbolic links. fs is brtfs. I have not tried browsing /proc and did not create symbolic links there.
Comment 4 Bug Janitor Service 2023-01-02 14:11:57 UTC
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/485
Comment 5 Fabian Vogt 2023-01-09 07:55:50 UTC
Git commit 491068a4405f93ce66d4f49fa5ba5dee29e9546b by Fabian Vogt.
Committed on 08/01/2023 at 17:18.
Pushed by fvogt into branch 'release/22.12'.

Don't recurse into symlinks when counting directory contents

Symlink contents should not be visited for the purpose of displaying sizes.
Not only is potentially misleading because the storage is actually used
elsewhere (the target location), it can be completely wrong as contents can
be visited multiple times, even recursively.

M  +3    -9    src/kitemviews/private/kdirectorycontentscounterworker.cpp

https://invent.kde.org/system/dolphin/commit/491068a4405f93ce66d4f49fa5ba5dee29e9546b
Comment 6 Fabian Vogt 2023-01-09 15:22:03 UTC
Git commit a81b287e7af7db24ff26a659fe599e5a8b290bd1 by Fabian Vogt.
Committed on 09/01/2023 at 15:21.
Pushed by fvogt into branch 'master'.

Don't recurse into symlinks when counting directory contents

Symlink contents should not be visited for the purpose of displaying sizes.
Not only is potentially misleading because the storage is actually used
elsewhere (the target location), it can be completely wrong as contents can
be visited multiple times, even recursively.
(cherry picked from commit 491068a4405f93ce66d4f49fa5ba5dee29e9546b)

M  +3    -9    src/kitemviews/private/kdirectorycontentscounterworker.cpp

https://invent.kde.org/system/dolphin/commit/a81b287e7af7db24ff26a659fe599e5a8b290bd1