While debugging another Thunar bug, I somehow managed to trigger this one. And it won't go away. I realize that I must be a pain in the butt with all these bugs I'm filing, but trust me, I only have the best intentions in mind. Whenever I press refresh (e.g. inside my home dir), Thunar enters an infinite loop on some thread. The mouse cursor rapidly flickers between normal and busy, and CPU usage rises on one core. Thunar remains usable however. Killing all Thunar processes or even rebooting didn't help, the loop starts as soon as refresh is pressed, even after a fresh start. The only solution I found so far is to downgrade to 1.6.6, which doesn't exhibit this behavior. The Thunar daemon process rapidly spams this message: (Thunar:23058): thunar-CRITICAL **: thunar_file_reload: assertion '(((__extension__ ({ GTypeInstance *__inst = (GTypeInstance*) ((file)); GType __t = ((thunar_file_get_type ())); gboolean __r; if (!__inst) __r = (0); else if (__inst->g_class && __inst->g_class->g_type == __t) __r = (!(0)); else __r = g_type_check_instance_is_a (__inst, __t); __r; }))))' failed
I haven't seen this yet. Does this only happen with a manual refresh? If you can reproduce it somehow, then the next step would be to git bisect which commit causes this.
Yeah, only with manual refresh. Files that are changed are updated fine, without triggering the loop. I'll do a bisect when I have some more time, hopefully soon.
On a second thought, probably you will only find the commit that enabled full manual refresh. Even so, that information might be helpful. So it's worth a try.
Reverting b2012f58da7ba8e8bf28aaca2b5cde45552ce0c3 fixes the problem for me.
Created attachment 6215 do-not-reload-in-idle.patch Maybe we can narrow down the issue a bit more. Can you try if this patch fixes the problem? If it does not - which is very likely, or maybe it makes it worse -, maybe simply removing the second thunar_file_reload_idle (that one for the folder->corresponding_file) will? Do you have any symlinks in that directory? Does it always happen in the same directory and not in others? If yes, is there something special about it?
It happens in every directory, even in empty ones. That patch actually seems to fix the issue!
If that helps, good. Please test this for a while though, to be sure it does not simply camouflage the problem. Use folders with lots of files, with only a few files, maybe remote files etc.
I don't seem to be able to trigger this bug again. I had one instance of Thunar consuming 100% CPU, but that was likely not due to a refresh, but bug 10161. So for now I'd say that the patch works.
Created attachment 6216 alternative-patch-1.patch Thanks for testing. I'm a bit curious about the real cause, can you give these two alternative patches a try too?
Created attachment 6217 alternative-patch-2.patch 2nd alternative patch
This bug happens with both attachment 6216 or attachment 6217
Ok, thanks. I'll simply push the first patch to master later.
Pushed to master: http://git.xfce.org/xfce/thunar/commit/?id=ea00375c7d041105033678d5515b651a34e1804d
Excellent, thank you.
Actually, I just noticed another way the infinite loop issue can be triggered, and it's not fixed by attachment 6215 . Something is really going on with Thunar lately, it seems the latest updates seem to have broken it left and right :( 1. Create dir 'foo' in location A 2. Create file 'foo' in location B 3. Open A and B in separate windows 4. Drag'n'drop foo from A to B, overwriting the file in the process 5. Thunar in B now consumes 100% CPU
Not reproducible here, and I've tried it several times and with different approaches (create files first, then open thunar windows, open thunar windows then create files,...). Please do not reopen old bugs just because you believe it is the same issue. This was only about an infinite loop caused by manual refresh and has nothing to do with your new issue. Please open a new bug report for this and do a git bisect to find the offending commit if you can reliably reproduce this.
(In reply to Harald Judt from comment #16) > Please do not reopen old bugs just because you believe it is the same issue. > This was only about an infinite loop caused by manual refresh and has > nothing to do with your new issue. Please open a new bug report for this and > do a git bisect to find the offending commit if you can reliably reproduce > this. Yes, indeed, it probably was a separate issue. Just as a note, in 1.6.10, this issue also appears fixed, so I won't be opening a new bug for it.