@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.
- /* 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.
@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. sse2_unaligned () from /usr/lib/libc.so.6 sse2_unaligned () from /usr/lib/libc.so.6 file_compare_ by_name (file_a= 0x7fffe0018ab0, file_b= 0x7fffe001d040, sensitive= -1) at thunar-file.c:4024 list_model_ cmp_func (a=0x7fffe0018ab0, b=0x7fffe001d040, data=0x830ea0) at thunar- list-model. c:1045 libglib- 2.0.so. 0 libglib- 2.0.so. 0 insert_ sorted_ iter () from /usr/lib/ libglib- 2.0.so. 0 insert_ sorted () from /usr/lib/ libglib- 2.0.so. 0 list_model_ files_added (folder=0x82f060, files=0x7ffffff fdf00, list-model. c:1261 libgobject- 2.0.so. 0 libgobject- 2.0.so. 0 emit_valist () from /usr/lib/ libgobject- 2.0.so. 0 libgobject- 2.0.so. 0 folder_ monitor (monitor=0xc865f0, event_file= 0xc498c0, file=0xc49ae0, event_type= G_FILE_ MONITOR_ EVENT_MOVED, user_data=0x82f060) libffi. so.6 libffi. so.6 marshal_ generic_ va () from /usr/lib/ libgobject- 2.0.so. 0 libgobject- 2.0.so. 0 emit_valist () from /usr/lib/ libgobject- 2.0.so. 0 libgobject- 2.0.so. 0 libgio- 2.0.so. 0 context_ dispatch () from /usr/lib/ libglib- 2.0.so. 0 libglib- 2.0.so. 0 libglib- 2.0.so. 0 libgtk- x11-2.0. so.0 e868) at main.c:312
0x00007ffff45ce60e in __strcmp_
(gdb) bt
#0 0x00007ffff45ce60e in __strcmp_
#1 0x0000000000451102 in thunar_
case_
#2 0x000000000046950a in thunar_
user_
#3 0x00007ffff4b615d4 in ?? () from /usr/lib/
#4 0x00007ffff4b61b1e in ?? () from /usr/lib/
#5 0x00007ffff4b62934 in g_sequence_
#6 0x00007ffff4b62a0c in g_sequence_
#7 0x000000000046a091 in thunar_
store=0x830ea0) at thunar-
#8 0x00007ffff4e1dfa5 in g_closure_invoke () from /usr/lib/
#9 0x00007ffff4e2ffb2 in ?? () from /usr/lib/
#10 0x00007ffff4e38c1c in g_signal_
#11 0x00007ffff4e38fff in g_signal_emit () from /usr/lib/
#12 0x00000000004535dd in thunar_
other_
at thunar-folder.c:752
#13 0x00007fffeff701c8 in ffi_call_unix64 () from /usr/lib/
#14 0x00007fffeff6fc2a in ffi_call () from /usr/lib/
#15 0x00007ffff4e1ecba in g_cclosure_
#16 0x00007ffff4e1e1d4 in ?? () from /usr/lib/
#17 0x00007ffff4e3890d in g_signal_
#18 0x00007ffff4e38fff in g_signal_emit () from /usr/lib/
#19 0x00007ffff515dc29 in ?? () from /usr/lib/
#20 0x00007ffff4b48dd7 in g_main_
#21 0x00007ffff4b49040 in ?? () from /usr/lib/
#22 0x00007ffff4b49362 in g_main_loop_run () from /usr/lib/
#23 0x00007ffff6a2a347 in gtk_main () from /usr/lib/
#24 0x00000000004248b8 in main (argc=1, argv=0x7fffffff
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 1.6.10/ thunar/ thunar- folder. c 2016-08-03 11:58:02.076666668 +0000 1.6.10- fix/thunar/ thunar- folder. c 2016-08-03 11:57:28.846666000 +0000 folder_ monitor (GFileMonitor >content_ type_idle_ id != 0) >content_ type_idle_ id);
--- Thunar-
+++ Thunar-
@@ -737,8 +737,11 @@ thunar_
if (folder-
restart = g_source_remove (folder-
- /* if we don't have it, add it if the event is not an "deleted" event */ MONITOR_ EVENT_DELETED) ) MONITOR_ EVENT_DELETED MONITOR_ EVENT_MOVED) )
- if (G_UNLIKELY (lp == NULL && event_type != G_FILE_
+ /* 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_
+ && event_type != G_FILE_
{
/* 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 */ signals[ FILES_ADDED] , 0, &list);
list.data = file; list.next = list.prev = NULL;
g_signal_emit (G_OBJECT (folder), folder_
It is passing the address of a local GList variable to the "files added" signal
handler. This needs further investigation as potential stack corruption.