Thunar crash while copying files (segfault / possible clash with gnome.zeitgeist.Engine)

Created attachment 6479
Thunar Crash Report

When I cut more than 1 files and paste it somewhere else (on the same window); Thunar crashes! The full output of the process is attached (from the second I open Thunar till the crash).

I'm using up-to-date ArchLinux with Thunar 1.6.10

Unfortunately, the output is not of much use; please provide a gbd backtrace.

(In reply to Harald Judt from comment #1)
> Unfortunately, the output is not of much use; please provide a gbd backtrace.

How can I get this "gbd backtrace"??

Created attachment 6521
Debug session + backtrace

I did the following: Create a simple text file in /home/user/test.txt, create an empty directory /home/user/test, cut test.txt and paste it under /home/user/test, drag test.txt in the location selector (pathbar style) to /home/user, repeat until thunar crashes (happens with both directions). Attached is a debug session including backtrace.

I have the same problems with Thunar as outlined in this thread. There are a lot of other people out there who are affected, too, both on Arch, Ubuntu and other major distributions. See e.g.

https://bbs.archlinux.org/viewtopic.php?id=203663&p=2
https://<email address hidden>/msg1367689.html

On the practical side, I can reliably reproduce the bug, but can't run any gdb debug session, because Fedora 23 doesn't provide the necessary debug infos needed by gdb.

Is there something else I can do to help?

By the way, the message when Thunar crashes is this one:

Thunar[1653]: segfault at 2 ip 00007f87c2a2c07d sp 00007fff45204d98 error 4 in libgobject-2.0.so.0.4600.1[7f87c29f8000+50000]

And here's what's in /var/log/messages:

Nov 9 08:46:41 chiara systemd-coredump: Process 2025 (Thunar) of user 1000 dumped core.#012#012Stack trace of thread 2025:#012#0 0x00007f1b733eaa98 __GI_raise (libc.so.6)#012#1 0x00007f1b733ec69a __GI_abort (libc.so.6)#012#2 0x00007f1b7342de1a __libc_message (libc.so.6)#012#3 0x00007f1b73439d28 malloc_printerr (libc.so.6)#012#4 0x00007f1b739e35ee g_free (libglib-2.0.so.0)#012#5 0x0000559ac4208c1c thunar_file_info_clear (thunar)#012#6 0x0000559ac420a19d thunar_file_load (thunar)#012#7 0x0000559ac420a253 thunar_file_reload (thunar)#012#8 0x00007f1b739dde3a g_main_dispatch (libglib-2.0.so.0)#012#9 0x00007f1b739de1d0 g_main_context_iterate (libglib-2.0.so.0)#012#10 0x00007f1b739de4f2 g_main_loop_run (libglib-2.0.so.0)#012#11 0x00007f1b75902f37 IA__gtk_main (libgtk-x11-2.0.so.0)#012#12 0x0000559ac41f1e85 main (thunar)#012#13 0x00007f1b733d6580 __libc_start_main (libc.so.6)#012#14 0x0000559ac41f1fc9 _start (thunar)#012#012Stack trace of thread 2116:#012#0 0x00007f1b734b2d89 syscall (libc.so.6)#012#1 0x00007f1b73a2299a g_cond_wait_until (libglib-2.0.so.0)#012#2 0x00007f1b739b2c09 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0)#012#3 0x00007f1b73a051a6 g_thread_pool_wait_for_new_task (libglib-2.0.so.0)#012#4 0x00007f1b73a04835 g_thread_proxy (libglib-2.0.so.0)#012#5 0x00007f1b7377e60a start_thread (libpthread.so.0)#012#6 0x00007f1b734b8bbd __clone (libc.so.6)#012#012Stack trace of thread 2117:#012#0 0x00007f1b734b2d89 syscall (libc.so.6)#012#1 0x00007f1b73a2299a g_cond_wait_until (libglib-2.0.so.0)#012#2 0x00007f1b739b2c09 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0)#012#3 0x00007f1b73a051a6 g_thread_pool_wait_for_new_task (libglib-2.0.so.0)#012#4 0x00007f1b73a04835 g_thread_proxy (libglib-2.0.so.0)#012#5 0x00007f1b7377e60a start_thread (libpthread.so.0)#012#6 0x00007f1b734b8bbd __clone (libc.so.6)#012#012Stack trace of thread 2026:#012#0 0x00007f1b734ad11d poll (libc.so.6)#012#1 0x00007f1b739de16c g_main_context_poll (libglib-2.0.so.0)#012#2 0x00007f1b739de27c g_main_context_iteration (libglib-2.0.so.0)#012#3 0x00007f1b739de2b9 glib_worker_main (libglib-2.0.so.0)#012#4 0x00007f1b73a04835 g_thread_proxy (libglib-2.0.so.0)#012#5 0x00007f1b7377e60a start_thread (libpthread.so.0)#012#6 0x00007f1b734b8bbd __clone (libc.so.6)#012#012Stack trace of thread 2110:#012#0 0x00007f1b734b2d89 syscall (libc.so.6)#012#1 0x00007f1b73a2299a g_cond_wait_until (libglib-2.0.so.0)#012#2 0x00007f1b739b2c09 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0)#012#3 0x00007f1b73a051a6 g_thread_pool_wait_for_new_task (libglib-2.0.so.0)#012#4 0x00007f1b73a04835 g_thread_proxy (libglib-2.0.so.0)#012#5 0x00007f1b7377e60a start_thread (libpthread.so.0)#012#6 0x00007f1b734b8bbd __clone (libc.so.6)#012#012Stack trace of thread 2027:#012#0 0x00007f1b734ad11d poll (libc.so.6)#012#1 0x00007f1b739de16c g_main_context_poll (libglib-2.0.so.0)#012#2 0x00007f1b739de4f2 g_main_loop_run (libglib-2.0.so.0)#012#3 0x...

And of course, if you have any patches you want to apply and test me, feel free to send them. I'll recompile and report back in no time.

Created attachment 6526
gdb debug output

Hi,
can the attached gdb debug output be of any help?

Harald, what does the following commit do and is bug #11983 related to this issue?

http://git.xfce.org/xfce/thunar/commit/?id=029012f4c39d9d3d9ae617491a69f76f54a4192f

Htd, can you apply that patch (or just compile thunar from master) and see if that makes any difference.

Unfortunately, the problem stays the same with your patch applied, as well as the error message:

Thunar[25422]: segfault at 1 ip 00007ffad041307d sp 00007ffe93cfc658 error 4 in libgobject-2.0.so.0.4600.1[7ffad03df000+50000]

Attached is a gdb backtrace of the patched Thunar.

Created attachment 6527
GDB backtrace Thunar patched

Finally I managed to get all necessary debug information installed and being available to gdb. A new backtrace is attached.

Created attachment 6529
Backtrace Thunar

Whatever is causing this happened relatively recently because we're suddenly getting many reports and it seems to be fairly easy to trigger.

Downstream Ubuntu bug, see also duplicates: https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1514912

There are also some reports which show that the problem appeared right after updating to a glib2 > 2.44. Downgrading to glib2-2.44 fixed the problem, while upgrading made it re-appear. Unfortunately, downgrading to glib2-2.44 is impossible for me, because it requires recompiling a plethora of esential packages.

Likely a duplicate.

*** This bug has been marked as a duplicate of bug 12264 ***

NO! This is not a duplicate of that bug! These are two separate issues. I did test the 12264 bug, but it doesn't happen in my Thunar.

Harald: the preliminary workaround you posted here

http://bug-attachment.xfce.org/attachment.cgi?id=6530

fixes the problem for me. More precisely, about 10 trials in the last 15 minutes showed no crash. Will try more extensively tomorrow (but am quite sure the crash is gone).

Tried a little bit more and played with some files copying around, and Thunar crashed. Dmesg says:

Thunar[18324]: segfault at 20 ip 00005571980b12b2 sp 00007fffeed4a698 error 4 in thunar[557198076000+b9000]

So the workaround makes it harder to trigger the bug, but it's still there (or has altered now).

I don't wanted to post a duplicate, so I join the original bug poster: same behaviour for me too. Arch linux, X86_64, Thunar 1.6.10-2.

Same here. Arch linux too.

Hi,
as per today, the bug still seems to be unresolved. Is there any progress?

Same here, after installing the latest Fedora 23 with XFCE.
Thunar "out-of-the-box" crashes consistently when cut&paste files from one location to another.
This seems a very persistent bug, and very annoying indeed.

R.

I'm still getting random Thunar crashes. I gave up on newer distros and went back to Xubuntu 15.04 and for the most part Thunar is stable but then every now and then some condition is met which causes it to crash. Today it was moving files between windows yet again.

I wonder if a solution to these race conditions is to introduce an option to have file transactions like copying, moving, and renaming, QUEUED instead of done in parallel.