Hello, looks like bug 10161 has made a return, or wasn't fully fixed after all. In Thunar 1.8.8, it's possible that the tree view pane becomes out of sync with the main view. Example: - /home/me/foo/bar/baz/test exists. 'test' somehow triggered this particular bug. - Navigate to /home/me/foo/bar/baz - the tree view follows. - Navigate to /home/me/foo/bar/baz/test - the tree refuses to automatically expand, or enter this directory. It will show the parent dir as still being selected. - As the main view and tree view now show different things, Thunar will now consume 100% CPU until navigated to an unbugged directory. Unfortunately I cannot provide a reliable repro on how to "excommunicate" a directory. It happened after renaming it in Thunar, but not every rename triggers this bug. I suspect that the depth of the tree might be relevant, or the fact that it happened on an ecryptfs mount.
Sorry, so far no luck to reproduce the bug. Maybe there is there something special about the permsission set for for test and baz ? So you renamed "test" to e.g. "test2" and than did the steps above to trigger the bug ? A shot into the blue: Possibly the patch from here makes a difference ? https://bugzilla.xfce.org/show_bug.cgi?id=15743
Ok, I can now reproduce this bug, at leat on my setup. I think the trigger is a race condition in combination with symlinked directories. I have a directory /home/haarp/foo/bar/baz/. /home/haarp/foo is a symlink to /home/haarp/Private/foo/. /home/haarp/Private is an ecryptfs mount. I have a GTK bookmark to /home/haarp/foo/bar/baz/. Repro: 1. Close all Thunar windows/processes 2. Open the bookmark (via places plugin in panel) Two possible things may now happen. 3a. Thunar opens, the main view and sidebar show /home/haarp/foo/bar/baz/, everything is fine. 3b. Thunar opens, the main view shows /home/haarp/foo/bar/baz, the sidebar is stuck at /home/haarp/foo/bar/ or even /home/haarp/foo/ and refuses to follow deeper. The bug has triggered. 100% CPU usage will follow when attempting to traverse even deeper. Start over at 1 to either trigger or not trigger the bug. Where do I best start to debug this? I will test the patch you mentioned shortly.
No, that patch did not fix the problem. The only difference I can spot is that the sidebar won't even mark the current directory anymore.
Wow, that is a heavy reproducer :P Since I dont have a ecryptfs, I tried reproducing it by linking to some usb flashdrive. And yes, after ~10 attempts I as well got the bug ! I was not able to reproduce the bug when only using the local filessystem ... possibly access is to fast to show the bug. You dont need the bookmark and the places plugin. It is sufficient to start thunar with the problematic folder as argument. E.g: thunar /home/schwinn/software/thunar_test/tree_view_100CPU/foo/bar/baz/ > Where do I best start to debug this? "thunar_tree_view_cursor_idle" in thunar-tree-view.c:2500, thats the method which will be called infinite until the full tree is build (until done = TRUE)
Yay, I'm not crazy, the bug is real! :) Yeah, I wanted to make sure it's reproducible, so I added every factor I could think of. From a cursory glance at the code and a debugger, I can't figure out why this happens. But I don't know the code well.
Still happening. I have a path that is 100% reproducible on my system. Unfortunately I don't understand Thunar well enough to really debug. :(
(In reply to haarp from comment #6) > Still happening. I have a path that is 100% reproducible on my system. If somebody posts a patch / the bug gets closed, you will be noticed from bugzilla. Otherwise the bug will stay unfixed. Currently I dont have time to debug it. It's on my list .. though that list is very long, and my time is very limited.
I think I'm coming across this bug in my cluster where people have a remote desktop session and use a lot of FUSE based mounts. If anybody is reading this who wants to look into this, I would love to provide a bounty.
(In reply to Maran from comment #8) > If anybody is reading this who wants to look into this, I would love to > provide a bounty. You can do that on bountysource: https://www.bountysource.com/issues/78398860-thunar-tree-pane-becomes-out-of-sync-and-uses-100-cpu
Awesome, thanks for letting me know.
> Still happening. Which version is that? The latest is 1.8.14.
Created attachment 9762 diff I used the scenario from comment #4 as testing ground and I was able to trigger the bug (or maybe it is just a related issue). The attached diff changes how thunar_tree_view_cursor_idle() checks if a folder is still being loaded so that really slow loading cases are properly handled.
Thanks Theo ! Though after 12 attempts with the patch, I still was able to trigger the bug. :/ To simplify reproducing it for everybody, here a minimal list what needs to be done: - Connect e.g. some flash drive (possibly a remote as well does the job .. probably connection just needs to be sufficient slow) - Create the folders "foo" with subfolder "bar" on that flash drive - Create symlink to foo on that drive. E.g: cd; ln -s /media/schwinn/USB_DISK/foo/ - ./thunar/thunar /home/schwinn/foo/bar (when launched from source folder ... check if three-view and location-buttons show the same folder. Repeat multiple times, until the bug triggers .. for me up to 20 attempts are required )
Improved reproducer, which always works on the first try for me: ./thunar/thunar -q;./thunar/thunar network:// & ./thunar/thunar /home/schwinn/foo/bar Reproducer works as well if some other root-node than "network://" is used. For some reason "computer://" and "trash://" do not work for the reproducer ... possibly the root needs to be below the usb to reproduce.
Created attachment 9768 Move iter initialization Comment #14 describes a different bug. It is caused by an oversight in the fix for bug 16024.
(In reply to Theo Linkspfeifer from comment #15) > Created attachment 9768 > Move iter initialization > > Comment #14 describes a different bug. It is caused by an oversight in the > fix for bug 16024. Thanks alot Theo, that was quick ! :P .. yes, seems like I found a different bug with the same symptoms :/ ... going back to re-check your first fix. Please ignore my "Improved reproducer" from comment #14 ! Maran and haarp: If you can, please as well take a try for the diff Theo attached in comment #12 Apply it to the code with: curl https://bugzilla.xfce.org/attachment.cgi?id=9762 | git apply Since this bug is tricky to reproduce, it would be nice to have as many testers as possible to be sure on its effect.
Ok, now I am positive that Theo's fix from comment#12 really fixes the bug. I used the reproducer from comment #12, but I added a deep path on the flashdrive, in order to see instantly if the bug occured or not (mkdir -p a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p) .. so I wont miss bug occurances, by overlooking "bar not opened in tree-view" when testing quickly. Tests without the fix: Bug occured after 20 attempts Bug occured after 10 attempts Bug occured after 10 attempts Bug occured after 26 attempts Bug occured after 17 attempts Tests with the fix: No bug occured after 70 attempts (Possibly I got the testing wrong in Comment #13 .. for sure I can say that Theo's patch relaxes the situation alot for me) Nevertheless, I would be happy if all of you take a try on it, if possible !
I never tried to build Thunar from source yet but I will do so this week and get back with the results.
(In reply to Maran from comment #18) > I never tried to build Thunar from source yet but I will do so this week and > get back with the results. Thanks alot ! Side note: Using "stress --cpu" ( or --io, or --vm or --hdd) did not help for me to reproduce the bug faster
Sorry to go a bit off-topic, I'm trying to build this on a 18.04 production server to make sure the environment is the same as the way I'm seeing the bug but I'm having a hard time to get a build environment working. Is there a Docker container of some sort with a complete build dev or some other smart trick I can use?
(In reply to Maran from comment #20) > Sorry to go a bit off-topic, I'm trying to build this on a 18.04 production > server to make sure the environment is the same as the way I'm seeing the > bug but I'm having a hard time to get a build environment working. Is there > a Docker container of some sort with a complete build dev or some other > smart trick I can use? I did not try it myself, though there is this one: https://hub.docker.com/r/schuellerf/xfce-test
After a bit of trial and error I got it to build. I first built the head of the master branch from the Github mirror (1.8.13-51c49943) without the patch. On this version I had a success rate of 100% of hitting the bug using a FUSE mount. I applied the patch on this same version and have not been able to replicate it the issue after this :D
(In reply to Maran from comment #22) > After a bit of trial and error I got it to build. > > I first built the head of the master branch from the Github mirror > (1.8.13-51c49943) without the patch. On this version I had a success rate of > 100% of hitting the bug using a FUSE mount. > > I applied the patch on this same version and have not been able to replicate > it the issue after this :D These are great news \o/, thanks alot for testing ! I'll push the fix to 4.14 and master ... to be further tested to make sure there is no regression. Regarding bountysource.com, best contact Theo directly to sort things out. (Thanks alot for the donation !)
Theo Linkspfeifer referenced this bugreport in commit 5e4d7cc1f6f7b8e001b05b7dd8633d8e380fbac0 Fix check if folder is fully loaded when expanding path in tree view. Prevents 100% CPU load and loosing sync with main view in some cases. (Bug #15762) https://git.xfce.org/xfce/thunar/commit?id=5e4d7cc1f6f7b8e001b05b7dd8633d8e380fbac0
Theo Linkspfeifer referenced this bugreport in commit 93718dffb9a30e17b2fc2c050e752bee7abb05a1 Fix check if folder is fully loaded when expanding path in tree view. Prevents 100% CPU load and loosing sync with main view in some cases. (Bug #15762) https://git.xfce.org/xfce/thunar/commit?id=93718dffb9a30e17b2fc2c050e752bee7abb05a1
Pushed .. fix will be released in thunar 1.8.15 ( and 1.9.0 later on )
I can also confirm that the patch in comment 12 seems to fix the bug. I haven't been able to reproduce it with my usual path. Thanks a lot! I'll continue to monitor it.
(In reply to alexxcons from comment #23) > > Regarding bountysource.com, best contact Theo directly to sort things out. > (Thanks alot for the donation !) Is there anything I need to do to release the funds or is that all built into the platform?
(In reply to haarp from comment #27) > I can also confirm that the patch in comment 12 seems to fix the bug. I > haven't been able to reproduce it with my usual path. Thanks a lot! I'll > continue to monitor it. Thank you as well for testing, good to know it's as well fixed for you ! (In reply to Maran from comment #28) > (In reply to alexxcons from comment #23) > > > > Regarding bountysource.com, best contact Theo directly to sort things out. > > (Thanks alot for the donation !) > > Is there anything I need to do to release the funds or is that all built > into the platform? First time for me that a bug with a bounty got fixed :P https://www.bountysource.com/issues/78398860-thunar-tree-pane-becomes-out-of-sync-and-uses-100-cpu I see a button "Claim bounty" there. So I guess Theo needs to register on bountysource.com and push that button .. than you probably have to acknowledge to release the bounty to him.