Comment 233 for bug 1512120

(In reply to pgkos.bugzilla from comment #155)
> I am sending a simple patch which wraps the renaming code and the folder
> monitor code in a mutex.
> I suppose that the main reason for the crash is that when we call in
> thunar-file.c:1932:
> g_file_set_display_name (file->gfile, name, cancellable, error);
> this call sends a signal which is connected to the folder monitor. The
> folder monitor runs on another thread. The thunar_folder_monitor function
> gets called immediately and it sends some signals which call
> thunar_list_model_files_added, which then uses thunar_file_compare_by_name
> as comparison function.
> The problem is, we have our original, "renaming" thread, which at one point
> calls thunar_file_info_clear. If we are at the end of this clearing function
> and then the thread switches and the code from thunar_file_compare_by_name
> continues, it will segfault because all members of ThunarFile structure are
> now null.
> The solution is to prevent starting the code of thunar_folder_monitor until
> the renaming procedure is completed so all ThunarFile members are already
> updated.
> So, I have added an extern "rename" mutex which is acquired in these two
> functions.
> The mutex must be acquired before the call to g_file_set_display_name.
> Also, there is a simple method to trigger the segfault:
> - add a 1-second sleep as the last line of the thunar_file_info_clear
> function
> - add a 0.5-second sleep as the first line of the thunar_folder_monitor
> (you can add some conditional checks to prevent long pause when loading
> Thunar)
> - compile and test

While your patch may prevent the crash it also seems to inhibit refreshing of the folder contents. Concretely, thunar seems to get stuck in the refresh thread.

For the future and anyone trying to help with fixing this: if your patch does not pass the testcase linked here, it's not really fixing it.

Please note that you have to run the rename loop in your terminal for a while in order to expose the race condition.