Created attachment 7069 gdb trace Thunar hangs not allowing any input to window. Eventually giving 'do you want to close' dialogue. Closes without further issue. gsb trace attached after attaching to pid. strace just gives this when attached to running thunar pid futex(0x562c4f5889e8, FUTEX_WAIT_PRIVATE, 2, NULL
Okay, so from the GDB trace we see that one thread is stuck at: thunar_file_monitor (monitor=<optimised out>, event_path=0x562c507922a0, other_path=0x562c50b92fa0, event_type=G_FILE_MONITOR_EVENT_MOVED, user_data=<optimised out>) at thunar-file.c:822 This line is: G_LOCK (file_rename_mutex); Which was added to try to fix bug #12264. So this is a mutex deadlock. My best guess (which I mentioned on the other bug) is that this is something to do with thumbnails. When a file gets moved/renamed, thunar also renames the thumbnail cache file (which I think lives in ~/.cache/thumbnails) to match. This is done inside the mutex, and of course it triggers a further G_FILE_MONITOR_EVENT_MOVED, which has to wait for the mutex to unlock before it can complete.
(Copying my comment over from the other bug) The problem appears to be as follows: 1. A file in that directory gets renamed. 2. G_FILE_MONITOR_EVENT_MOVED happens on thread A. 3. The mutex gets locked. 4. The thumbnail associated with the file gets renamed. 5. G_FILE_MONITOR_EVENT_MOVED happens for the thumbnail on thread B. 6. Thread B waits on the mutex to unlock. 7. Thread A won't unlock the mutex until thread B finished. This all seems to be a result of: thunar_file_move_thumbnail_cache_file (event_path, other_path); now being inside the mutex. The previous crash was likely caused by a similar chain of events, eg check out this bug report which specifically mentions move_thumbnail: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800723;msg=91
Created attachment 7074 Deadlock fix It seems that mutex may be not released due to return statement in thunar_file_monitor function. This will cause deadlocks. > G_LOCK (file_rename_mutex); > ... > if (other_file == NULL) > return; > ... > G_UNLOCK (file_rename_mutex); I'm attaching the patch which solves this problem. Thunar no more hangs for me.
That patch appears to fix the issue for me. Thanks.
Well spotted. Patch looks reasonable to me. +1
*** Bug 13500 has been marked as a duplicate of this bug. ***
I built thunar with Viktor's patch and found that after I logged out and logged back in, bug#13472 is fixed by it as well. I actually think that bug#13481 and bug#13500 are duplicates of my original report, bug#13472 :) Thanks for the diligence and the patch.
Patch pushed to master: https://git.xfce.org/xfce/thunar/commit/?id=4dd549db77838c9345f10a72f10e705f8ae327d4
Viktor Odintsev referenced this bugreport in commit 4dd549db77838c9345f10a72f10e705f8ae327d4 Fix deadlock in mutex causing Thunar to hang (Bug #13481) https://git.xfce.org/xfce/thunar/commit?id=4dd549db77838c9345f10a72f10e705f8ae327d4
This bug really grinds my gears. Thanks to everyone who helped nail it dfown & fix it... but... I'm on F26 now, and it's still using 1.6.11, with this bug. Can anyone say which version the bugfix will appear in? I hope we're not going to have to wait for this 1.8 milestone, that sounds like it'd be 10 years away.
Woah! Nevermind. I found the master branch on github and i can see the fix has been included in 1.6.12 which is in rawhide already. Nice work guise & goilse. :-)
Seriously though, I hope someone can push 1.6.12 out of rawhide and into F26. Thunar is practically unusable with this bug. You're browsing around, you leave Thunar, do some work, basically anything that modifies files Thunar is looking at, and when you go back to Thunar it's an unresponsive slab of grey pixels. No good. Pls push this into F26 ASAP. Many thanks.
Closing, the fix is available in thunar-1.6.12. Thanks Viktor(ninetls)!
*** Bug 13472 has been marked as a duplicate of this bug. ***