[Xfce-bugs] [Bug 12264] Crash when renaming single file in folder

[bugzilla-daemon at xfce.org]

https://bugzilla.xfce.org/show_bug.cgi?id=12264

--- Comment #96 from Roy Richardson <rocketx86 at gmail.com> ---
(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.