This is with thunar-1.6.10: (line numbers will be off because I was
adding debug printfs)
thunar_file_info_reload() touches memory deleted by thunar_folder_reload()
I don't think this is a thread race because I always see both
functions running on the same thread.
What I think is happening here:
g_idle_add((GSourceFunc) thunar_file_reload, file);
This defers a call of thunar_file_reload(file) until after
thunar_folder_reload() has deleted "file"
The crash looks like this in valgrind:
==12276== Process terminating with default action of signal 11 (SIGSEGV)
==12276== Access not within mapped region at address 0x0
==12276== at 0x4362BA: thunar_file_info_reload (thunar-file.c:977)
==12276== by 0x436720: thunar_file_load.constprop.8 (thunar-file.c:1179)
==12276== by 0x4367BF: thunar_file_reload (thunar-file.c:3931)
==12276== by 0x7E37E89: g_main_context_dispatch (in
==12276== by 0x7E3822F: g_main_context_iterate.isra.29 (in
==12276== by 0x7E38551: g_main_loop_run (in
==12276== by 0x5E0A586: gtk_main (in
==12276== by 0x41FBF8: main (main.c:314)
glib's g_main_context_dispatch() is calling into thunar_file_reload(),
which means it came via g_idle_add.
Then we get to this part of thunar_file_info_reload():
/* determine the basename */
file->basename = g_file_get_basename (file->gfile); //
if (strcmp (file->basename, "kmsg") == 0 //
 "file" has been freed, so the read (of gfile) and write (of
basename) are "invalid read/write of size 8" according to valgrind,
but don't crash.
g_file_get_basename() writes to the terminal:
(thunar:13169): GLib-GIO-CRITICAL **: g_file_get_basename: assertion
'G_IS_FILE (file)' failed
 file->basename is set to NULL, so the strcmp() attempt causes SIGSEGV.
(strcmp doesn't appear in the backtrace because it gets compiled to a
"repz cmpsb" instruction)
If I comment out the g_idle_add, the bad memory accesses seem to go away.
I'm not sure what the right fix for this is though.