Under certain conditions, Thunar is stuck using 100% CPU on one core. Steps to reproduce: 1) Have side pane in "Tree" mode 2) Open network share (e.g. sftp://server) 3) Enter random director (e.g. sftp://server/data) 4) Cut network connection 5) Let the network share timeout and disappear 6) Open network share again (e.g. sftp://server) 7) (Side bug: The location will now show up as empty!) 8) Enter sftp://server/data again Thunar will now use 100% CPU as long as the side pane is opened.
I'm pretty sure this has to do with the sidebar now. After the connection is cut nad I open sftp://server, I receive an empty directory. A refresh is NOT working and will not re-establish the connection (a bug in itself!!). When I now open sftp://server/data, the connection is re-established. That's where things go wrong. The tree probably tries to show sftp://server/data, but it still believes that sftp://server is empty, causing problems. If I now (that the connection is properly established) go up to the main view of sftp://server and refresh, Thunar finally notices that itr isn't empty and the tree view in the sidebar starts working properly, and the CPU usage decreases.
After bug 11843 has been somewhat improved, this bug triggers more often. Under certain conditions, the tree pane gets stuck. Reconnecting a gvfs share is just one example. When the tree pane is (being stuck) in a different directory than the main view, 100% CPU usage is the result. I suspect that the tree view has a check to prevent it from entering an invalid location, but has no check to determine if a previously invalid location has become valid again. Thus there is a loop of: - Tree view wants to enter same location as main view - Location is invalid, abort - Repeat Harald, do you mind if I CC you? You've been pretty good with these loop problems in the past :)
Thunar-1.6.11, still happening. Repro steps are still mostly the same: 1) Have side pane in "Tree" mode 2) Open network share (e.g. sftp://server) 3) Enter random directory (e.g. sftp://server/data/foo) and keep it open 4) Cut network connection, let the network share timeout and disappear 5) Try going back in the window from step 3 -> Thunar complains it doesn't exist anymore, will be removed from history 6) Re-establsih connection to network share 7) Navigate to sftp://server/data -> the main view can enter the dir, the tree view acts like it doesn't exist. -> 100% CPU usage. So there's two bugs: a) Main view and tree view do not always agree on which dirs exist b) Whenever Thunar enters a dir that the tree view thinks doesn't exist, it keeps the CPU busy
Still happening in Thunar 1.8.1. I have an easier reproduction now. 1) Have a server that allows access to /foo, but denies permission to / 2) Open share in Thunar (sftp://server/foo) 3) Open Thunar side pane in tree view mode Thunar now uses 100% CPU, presumably trying to access/display the tree which it doesn't have full access to.
Thanks for all the details ! Bug #14900 most likely is a duplicate of this one, though it triggers the bug on a local filesystem. I attached a preleminary fix there .. would be great if you could give it a spin, to see if it is the same problem. A proper fix is in work.
(In reply to alexxcons from comment #5) > Thanks for all the details ! > > Bug #14900 most likely is a duplicate of this one, though it triggers the > bug on a local filesystem. > > I attached a preleminary fix there .. would be great if you could give it a > spin, to see if it is the same problem. > > A proper fix is in work. Hey, Attachment 8179 solves the problem with high CPU usage indeed! It doesn't fix the sidebar itself, but at least now I don't have a CPU core looping pointlessly. Thanks!
yw ... meanwhile I have a serious fix for the bug, as well fixing the sidebar: https://bugzilla.xfce.org/attachment.cgi?id=8196 Would be great if you could give it a try !
Gna, patch was mix of 2 commits, should be fine now: Bug #14900
Fix now pushed .. time to close this one. For the unlikely case that it is not a duplicate to #14900, please reopen ! *** This bug has been marked as a duplicate of bug 14900 ***
Thanks, Alex. I patched Thuanr 1.8.2 with commit 85a79da3f263596c88b0de6098226599b46a6304. Unfortunately, now Thunar crashes with a segfault when I reproduce the bug, instead of consuming CPU. Not sure if that's an improvement :) Backtrace: #0 0x00005555555a87b5 in thunar_file_get_info (file=0x0) at thunar-file.c:1483 #1 0x00005555556050cf in thunar_tree_view_cursor_idle (user_data=0x555555eeaf60) at thunar-tree-view.c:2552 #2 0x00007ffff4cbd4bd in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #3 0x00007ffff4cbf188 in ?? () from /usr/lib64/libglib-2.0.so.0 #4 0x00007ffff4cbf1bc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #5 0x00007ffff528a72d in g_application_run () from /usr/lib64/libgio-2.0.so.0 #6 0x0000555555589f78 in main (argc=1, argv=0x7fffffff4f88) at main.c:161
Created attachment 8243 a better patch crap, good that you noticed before next release. I cannot reporduce the seg.fault using a local folder without read permission. ( Can you please as well take a try with a local setup ? Possibly the crash is a remote-only problem. ) If I review my own bug, I have to say I was by far too sloppy :/ I now added missing NULL checks and added missing unref calls on ThunarFiles. Can you please take a try ?
Still segfaulting, however with a different backtrace #0 0x00005555555fd35b in thunar_tree_model_get_value (tree_model=0x555555e36540, iter=0x7fffffff4cc0, column=0, value=0x7fffffff4ab0) at thunar-tree-model.c:604 #1 0x00007ffff6719686 in gtk_tree_model_get_valist () from /usr/lib64/libgtk-3.so.0 #2 0x00007ffff67199d5 in gtk_tree_model_get () from /usr/lib64/libgtk-3.so.0 #3 0x000055555560519c in thunar_tree_view_cursor_idle (user_data=0x555555ee88d0) at thunar-tree-view.c:2575 #4 0x00007ffff4cbd4bd in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #5 0x00007ffff4cbf188 in ?? () from /usr/lib64/libglib-2.0.so.0 #6 0x00007ffff4cbf1bc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #7 0x00007ffff528a72d in g_application_run () from /usr/lib64/libgio-2.0.so.0 #8 0x0000555555589f78 in main (argc=1, argv=0x7fffffff4f88) at main.c:161 I can't reproduce it on local setups either, but I don't think that's even possible. You can't even enter directories if you don't have permission to its parent. And if you enter a directory beforehand, then remove the permissions of its parent, the tree view will just jump somewhere else. I think this bug is tied to gvfs wonkiness.
Created attachment 8244 next try Sorry, I was to fast with uploading the patch. Now I tested by using exactly the same scenario than you proposed above. Like that I was able to reproduce the crash. Should be fixed now. Could you please take another try ?
It appears to be working with this patch. Thanks!
Yay \o/ Thanks for testing !
Alexander Schwinn referenced this bugreport in commit 1129079405d0009137a17bad9908c3ad5d8c90bb Stuck tree pane makes Thunar use 100% CPU (bug #10161) https://git.xfce.org/xfce/thunar/commit?id=1129079405d0009137a17bad9908c3ad5d8c90bb
Alexander Schwinn referenced this bugreport in commit cdd2be21a0b18390186343d6e354fcf78511bf16 Stuck tree pane makes Thunar use 100% CPU (bug #10161) https://git.xfce.org/xfce/thunar/commit?id=cdd2be21a0b18390186343d6e354fcf78511bf16
Alexander Schwinn referenced this bugreport in commit 87731222ada23b24cfbb2c422d3ef2907c8fead3 Stuck tree pane makes Thunar use 100% CPU (bug #10161) https://git.xfce.org/xfce/thunar/commit?id=87731222ada23b24cfbb2c422d3ef2907c8fead3
fixed for master , 4.12 and 4.12 branch. Soon to be released in 1.8.3 and 1.6.16