(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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1512120 Title: [SRU] thunar crashes on file renaming To manage notifications about this bug go to: https://bugs.launchpad.net/thunar/+bug/1512120/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
