Comment 166 for bug 1512120

(In reply to Roy Richardson from comment #92)
> #4 0x00007ffff4e23c7a in g_object_unref () from /usr/lib/libgobject-2.0.so.0
> #5 0x000000000043d862 in thunar_file_info_clear (file=0x7fffe00203b0) at
> thunar-file.c:912

This is most likely due to multiple threads clobbering the GFileInfo within the same ThunarFile. At this point, I guess I would say that the basic design of sharing the common hash table of ThunarFiles between multiple threads is flawed. Worker threads ought to be using their own local copies until they're finished, and then send the data back to the main thread in a orderly fashion (probably making use of g_idle_add). I implemented something of the sort when I rewrote the playlist code of Audacious a few years ago.

Perhaps haarp is right (comment #80), the code just needs to be rewritten.