Not sure exactly what is causing this, but thunar in conjunction with gvfsd-metadata randomly maxes out my CPU and RAM. This time it happened when I was in a folder with 2 xslx, 2 ods and 2 pdf files. I have thumbnails set to 'Never'.
Designs
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
Thunar: 1.8.13git-43aa19aa
Tree View: yes, though as the thumbnails are rendered in the file/folder pane, the view shouldn't matter
Is there some means for me to run thunar in a particular mode that would track what is being done and once it triggers the massive CPU spikes I can kill the process and submit the results.
So that is one month old master ? (Sorry, no idea how to check to which branch that commit belongs to)
Does it as well happen with current master ?
Does it as well happen with bookmark-view ?
though as the thumbnails are rendered in the file/folder pane, the view shouldn't matter
What makes you think that it is related to thumbnails ?
Is there some means for me to run thunar in a particular mode that would track what is being done and once it triggers the massive CPU spikes I can kill the process and submit the results.
As I have libxfce4ui 4.15.0 from a PPA, I can't build newer versions of thunar due to this change.
I can't run current master, so no idea
This bug is irrelevant to whether its bookmark or tree view, as thumbnails are rendered in the file/folders pane and not sidebar pane.
What makes you think that it is related to thumbnails ?
You mentioned on IRC "Test with/without thumbnailer, delete generated thumbnails to check if thunar or tumbler is to blame." when i mentioned the issue happened in a folder with gimp .xcf files in it. https://imgur.com/raTiMeV.png
So it happened to me again yesterday and I think i've figured out somewhat where this is stemming from. I have various folders on my desktop folder that are symlinked to folders on my previous desktop and I noticed this time that when I opened the symlinked folder ( ~/Desktop/IOU symlinked to /home/jay/Desktop/IOU/ ) and then moved into one of its subfolder and then moved back to it, that the contents of the folder took forever to appear. Soon after that, the CPU spike happened. I tried different methods to try and create reproducible steps, but haven't been able to yet, but believe this is likely the cause that Thunar is having problems with.
On my Xubuntu 20.04, Thunar sometimes goes in a loop somewhere consuming 100% of a CPU core until killed. Haven't tried gdb so far. I don't know steps to reproduce but will try @philipzae 's hints.
I also often enter directories through symlink, so it might indeed be the same issue.
I have recently installed some dbgsym packages to get a stack trace for this bug I've created: xfwm4#405 . Willing to do the same for Thunar if useful.
Thank you for your attention.
Though Xubuntu is using 1.8.14, I am running a git build from May ( 1.8.13git-43aa19aa ) which include both patches. I've upgraded to 1.8.15 as it is available in the PPA and will see if it still happens.
Hi! Sorry for not responding to your comment one month ago, been very busy.
Yes, I have experienced at least one time when Thunar consumed 100% CPU in the last month and I had to kill it. Currently using 1.8.15 . I'm not 100% sure it's the same bug reported here.
I do not display icons on the desktop, but there is something common with @philipzae 's hints, as I often open symlinks to other filesystems.
Vague hints
My feeling is that the bug I experience is related to computing or displaying thumbnails, but it's not proven.
Next steps
Not reopening this issue for the sake of reducing noise. If/when I get some more specific information, I will reopen here or another bug or report a new one, depending on the observed facts.