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:
thunar_file_reload_idle() does:
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 /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==12276== by 0x7E3822F: g_main_context_iterate.isra.29 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==12276== by 0x7E38551: g_main_loop_run (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==12276== by 0x5E0A586: gtk_main (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.29)
==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); //[1]
if (strcmp (file->basename, "kmsg") == 0 //[2]
[1] "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
[2] 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.
Copying from https:/ /bugs.debian. org/cgi- bin/bugreport. cgi?bug= 800723# 96:
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:
thunar_ file_reload_ idle() does: add((GSourceFun c) thunar_file_reload, file); file_reload( file) until after folder_ reload( ) has deleted "file"
g_idle_
This defers a call of thunar_
thunar_
The crash looks like this in valgrind:
==12276== Process terminating with default action of signal 11 (SIGSEGV) file_info_ reload (thunar-file.c:977) file_load. constprop. 8 (thunar- file.c: 1179) file.c: 3931) context_ dispatch (in /lib/x86_ 64-linux- gnu/libglib- 2.0.so. 0.4600. 2) context_ iterate. isra.29 (in /lib/x86_ 64-linux- gnu/libglib- 2.0.so. 0.4600. 2) 64-linux- gnu/libglib- 2.0.so. 0.4600. 2) x86_64- linux-gnu/ libgtk- x11-2.0. so.0.2400. 29)
==12276== Access not within mapped region at address 0x0
==12276== at 0x4362BA: thunar_
==12276== by 0x436720: thunar_
==12276== by 0x4367BF: thunar_file_reload (thunar-
==12276== by 0x7E37E89: g_main_
==12276== by 0x7E3822F: g_main_
==12276== by 0x7E38551: g_main_loop_run (in /lib/x86_
==12276== by 0x5E0A586: gtk_main (in /usr/lib/
==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); //[1]
if (strcmp (file->basename, "kmsg") == 0 //[2]
[1] "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: get_basename: assertion
(thunar:13169): GLib-GIO-CRITICAL **: g_file_
'G_IS_FILE (file)' failed
[2] 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.