Comment 238 for bug 1512120

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, 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 ( looks promising).