(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.
(In reply to pgkos.bugzilla from comment #155) set_display_ name (file->gfile, name, cancellable, error); folder_ monitor function list_model_ files_added, which then uses thunar_ file_compare_ by_name file_info_ clear. If we are at the end of this clearing function file_compare_ by_name folder_ monitor until set_display_ name. file_info_ clear folder_ monitor
> 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_
>
> this call sends a signal which is connected to the folder monitor. The
> folder monitor runs on another thread. The thunar_
> gets called immediately and it sends some signals which call
> thunar_
> as comparison function.
>
> The problem is, we have our original, "renaming" thread, which at one point
> calls thunar_
> and then the thread switches and the code from thunar_
> continues, it will segfault because all members of ThunarFile structure are
> now null.
>
> The solution is to prevent starting the code of thunar_
> 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_
>
> Also, there is a simple method to trigger the segfault:
> - add a 1-second sleep as the last line of the thunar_
> function
> - add a 0.5-second sleep as the first line of the thunar_
> (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. packages. qa.ubuntu. com/qatracker/ milestones/ 361/builds/ 117794/ testcases/ 1681/results
http://
Please note that you have to run the rename loop in your terminal for a while in order to expose the race condition.