https://bugzilla.xfce.org/show_bug.cgi?id=12264
--- Comment #96 from Roy Richardson <[email protected]> --- (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 are receiving this mail because: You are the assignee for the bug. _______________________________________________ Xfce-bugs mailing list [email protected] https://mail.xfce.org/mailman/listinfo/xfce-bugs
