@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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1512120
Title:
[SRU] thunar crashes on file renaming
To manage notifications about this bug go to:
https://bugs.launchpad.net/thunar/+bug/1512120/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
