[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Pkg-xfce-devel] Bug#800723:

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
==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); //[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.

Reply to: