@slumbergod I have never triggered an desktop crash, but I have seen a
numerous seg faults from various types of move or rename operations.

@Kip This bug is definately elusive and has traits of a stack corruption. 

With debugging symbols enabled and NDEBUG defined to bypass the debugging
assertions, I was able to consistently catpure the following stack trace:

Thread 1 "thunar" received signal SIGSEGV, Segmentation fault.
0x00007ffff45ce60e in __strcmp_sse2_unaligned () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff45ce60e in __strcmp_sse2_unaligned () from /usr/lib/libc.so.6
#1  0x0000000000451102 in thunar_file_compare_by_name (file_a=0x7fffe0018ab0, file_b=0x7fffe001d040, 
    case_sensitive=-1) at thunar-file.c:4024
#2  0x000000000046950a in thunar_list_model_cmp_func (a=0x7fffe0018ab0, b=0x7fffe001d040, 
    user_data=0x830ea0) at thunar-list-model.c:1045
#3  0x00007ffff4b615d4 in ?? () from /usr/lib/libglib-2.0.so.0
#4  0x00007ffff4b61b1e in ?? () from /usr/lib/libglib-2.0.so.0
#5  0x00007ffff4b62934 in g_sequence_insert_sorted_iter () from /usr/lib/libglib-2.0.so.0
#6  0x00007ffff4b62a0c in g_sequence_insert_sorted () from /usr/lib/libglib-2.0.so.0
#7  0x000000000046a091 in thunar_list_model_files_added (folder=0x82f060, files=0x7fffffffdf00, 
    store=0x830ea0) at thunar-list-model.c:1261
#8  0x00007ffff4e1dfa5 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#9  0x00007ffff4e2ffb2 in ?? () from /usr/lib/libgobject-2.0.so.0
#10 0x00007ffff4e38c1c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#11 0x00007ffff4e38fff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#12 0x00000000004535dd in thunar_folder_monitor (monitor=0xc865f0, event_file=0xc498c0, 
    other_file=0xc49ae0, event_type=G_FILE_MONITOR_EVENT_MOVED, user_data=0x82f060)
    at thunar-folder.c:752
#13 0x00007fffeff701c8 in ffi_call_unix64 () from /usr/lib/libffi.so.6
#14 0x00007fffeff6fc2a in ffi_call () from /usr/lib/libffi.so.6
#15 0x00007ffff4e1ecba in g_cclosure_marshal_generic_va () from /usr/lib/libgobject-2.0.so.0
#16 0x00007ffff4e1e1d4 in ?? () from /usr/lib/libgobject-2.0.so.0
#17 0x00007ffff4e3890d in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#18 0x00007ffff4e38fff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#19 0x00007ffff515dc29 in ?? () from /usr/lib/libgio-2.0.so.0
#20 0x00007ffff4b48dd7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#21 0x00007ffff4b49040 in ?? () from /usr/lib/libglib-2.0.so.0
#22 0x00007ffff4b49362 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#23 0x00007ffff6a2a347 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#24 0x00000000004248b8 in main (argc=1, argv=0x7fffffffe868) at main.c:312

Eventually, I noticed the following:

In frame #12, a "file monitor move" signal is being handled. Subsequently,
In frame #7, a "files added" signal is being handled.

Should this be happening? No files are being created/added only moved.

I decided to see what would happen if "files added" wasn't signaled on a move. 
The results are promising. I am no longer able to crash Thunar with a rename.
I have created the following patch to stop the "files added" on "move event"
behavior. No other patches have been applied to Thunar 1.6.10 in testing.


diff -Naurp Thunar-1.6.10/thunar/thunar-folder.c Thunar-1.6.10-fix/thunar/thunar-folder.c
--- Thunar-1.6.10/thunar/thunar-folder.c	2016-08-03 11:58:02.076666668 +0000
+++ Thunar-1.6.10-fix/thunar/thunar-folder.c	2016-08-03 11:57:28.846666000 +0000
@@ -737,8 +737,11 @@ thunar_folder_monitor (GFileMonitor
       if (folder->content_type_idle_id != 0)
         restart = g_source_remove (folder->content_type_idle_id);
 
-      /* if we don't have it, add it if the event is not an "deleted" event */
-      if (G_UNLIKELY (lp == NULL && event_type != G_FILE_MONITOR_EVENT_DELETED))
+      /* if we don't have it, add it if the event is not an
+       * "deleted" or "moved" event */
+      if (G_UNLIKELY (lp == NULL 
+      && event_type != G_FILE_MONITOR_EVENT_DELETED
+      && event_type != G_FILE_MONITOR_EVENT_MOVED))
         {
           /* allocate a file for the path */
           file = thunar_file_get (event_file, NULL);


I'm suspicious of the following code fragment in thunar_folder_monitor which
I have now bypassed on "file monitor move" events with the above patch.

     /* tell others about the new file */
     list.data = file; list.next = list.prev = NULL;
     g_signal_emit (G_OBJECT (folder), folder_signals[FILES_ADDED], 0, &list);

It is passing the address of a local GList variable to the "files added" signal
handler. This needs further investigation as potential stack corruption.