Unfortunately, I have spotted yet another multithreading bug (I have verified it in gdb).
Basically, thunar_file_finalize function in thunar-file.c is not thread safe.
The reason why this function is bad is that when gobject's reference count reaches 0 (inside Glib's g_object_unref, see https://git.gnome.org/browse/glib/tree/gobject/gobject.c#n3177), thunar_file_finalize is not yet invoked. So, there is a possibility that another thread will get a file from the cache (hashtable), but that file already has a refcount == 0.
In particular, thunar_file_finalize conflicts with thunar_file_cache_lookup. For example, the following order of events will cause undefined behavior:
ThunarFile's refcount reaches 0 --> another thread calls thunar_file_cache_lookup and gets an invalid pointer to just-being-destroyed ThunarFile --> ThunarFile gets removed from the hashtable (too late).
Unfortunately, I have spotted yet another multithreading bug (I have verified it in gdb).
Basically, thunar_ file_finalize function in thunar-file.c is not thread safe.
The reason why this function is bad is that when gobject's reference count reaches 0 (inside Glib's g_object_unref, see https:/ /git.gnome. org/browse/ glib/tree/ gobject/ gobject. c#n3177), thunar_ file_finalize is not yet invoked. So, there is a possibility that another thread will get a file from the cache (hashtable), but that file already has a refcount == 0.
In particular, thunar_ file_finalize conflicts with thunar_ file_cache_ lookup. For example, the following order of events will cause undefined behavior:
ThunarFile's refcount reaches 0 --> another thread calls thunar_ file_cache_ lookup and gets an invalid pointer to just-being- destroyed ThunarFile --> ThunarFile gets removed from the hashtable (too late).
I am investigating the possible solutions (https:/ /github. com/jlindgren90 /thunar/ commit/ 9c6dbb1dae70 looks promising).