(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.
(In reply to Roy Richardson from comment #92) libgobject- 2.0.so. 0 file_info_ clear (file=0x7fffe00 203b0) at
> #4 0x00007ffff4e23c7a in g_object_unref () from /usr/lib/
> #5 0x000000000043d862 in thunar_
> 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.