(In reply to John Lindgren from comment #93) > 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.
Perhaps, but in the meantime, many people could use a temporary patch, including myself. Using only Harald's 'deactivate SEND_MOVE code paths' patch on 1.6.10, I've been able to capture another stack trace that indicates multiple threads clearing and reloading the GFileInfo within the same ThunarFile. (thunar:23134): GLib-CRITICAL **: g_utf8_casefold: assertion 'str != NULL' failed #2 0x00007ffff4b7854c in g_utf8_casefold () from /usr/lib/libglib-2.0.so.0 #3 0x000000000043dd3d in thunar_file_info_reload (file=0x7fffe001d5a0, cancellable=0x0) at thunar-file.c:1079 #4 0x000000000043dfdc in thunar_file_load (file=0x7fffe001d5a0, cancellable=0x0, error=0x0) at thunar-file.c:1193 I'm testing additional synchronization around critical sections containg calls to thunar_file_info_clear() and thunar_file_info_reload() in the following functions: thunar_file_load() thunar_file_get_with_info() thunar_file_get_async_finish() -- 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
