! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Thunar crash on cut/paste multiple files


Description Michael Ropy 2015-10-14 14:26:13 CEST
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
Comment 1 Harald Judt editbugs 2015-10-14 16:43:18 CEST
Unfortunately, the output is not of much use; please provide a gbd backtrace.
Comment 2 Michael Ropy 2015-10-17 20:58:51 CEST
(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"??
Comment 3 flo.xfce 2015-11-07 16:11:18 CET
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.
Comment 4 htd 2015-11-09 07:45:32 CET
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.


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?
Comment 5 htd 2015-11-09 08:50:13 CET
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  0x00007f1b73fff2c6 gdbus_shared_thread_func (libgio-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)
[root@chiara ~]#
Comment 6 htd 2015-11-09 08:54:20 CET
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.
Comment 7 htd 2015-11-09 16:02:16 CET
Created attachment 6526 
gdb debug output

can the attached gdb debug output be of any help?
Comment 8 Andrzej editbugs 2015-11-10 00:24:48 CET
Harald, what does the following commit do and is bug #11983 related to this issue?


Htd, can you apply that patch (or just compile thunar from master) and see if that makes any difference.
Comment 9 htd 2015-11-10 07:41:44 CET
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.
Comment 10 htd 2015-11-10 07:42:26 CET
Created attachment 6527 
GDB backtrace Thunar patched
Comment 11 htd 2015-11-11 07:23:15 CET
Finally I managed to get all necessary debug information installed and being available to gdb. A new backtrace is attached.
Comment 12 htd 2015-11-11 07:23:41 CET
Created attachment 6529 
Backtrace Thunar
Comment 13 Alistair Buxton 2015-11-13 12:25:49 CET
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
Comment 14 htd 2015-11-13 12:43:14 CET
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.
Comment 15 Harald Judt editbugs 2015-11-13 20:34:54 CET
Likely a duplicate.

*** This bug has been marked as a duplicate of bug 12264 ***
Comment 16 Michael Ropy 2015-11-13 20:38:52 CET
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.
Comment 17 htd 2015-11-13 22:49:34 CET
Harald: the preliminary workaround you posted here


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).
Comment 18 htd 2015-11-13 23:03:09 CET
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).
Comment 19 scar 2016-01-05 20:05:28 CET
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.
Comment 20 Alejandro Perez 2016-01-12 10:24:47 CET
Same here. Arch linux too.
Comment 21 htd 2016-01-19 09:13:17 CET
as per today, the bug still seems to be unresolved. Is there any progress?
Comment 22 Rob 2016-01-25 04:43:31 CET
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.

Comment 23 slumbergod 2016-01-30 21:50:04 CET
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.
Comment 24 Yves-Alexis Perez editbugs 2016-03-20 11:06:51 CET
*** Bug 12509 has been marked as a duplicate of this bug. ***
Comment 25 slumbergod 2016-03-26 00:41:05 CET
If anyone has any updates on whether Thunar under 16.04 LTS beta 2 is experiencing the crashing issues can you please post here. This thread seems to be the only public place people post news on this ongoing issue. 

Xubuntu 15.04 was the last version with a stable thunar/glib for me and, curiously, the release notes for 16.04 seem to point to very old bug reports rather than the current ones like this one.

And, of course, asking people associated with the dev team often invites flaming so I am hesitant to even ask here.

I have given up hope that these stability issues will be resolved anytime soon but I would like to know whether a clean install of 16.04 is going to take me back to the instabilities of 15.10. I love xfce and wouldn't use anything else but I don't want to move to newer versions that kill thunar.
Comment 26 slumbergod 2016-04-20 06:53:12 CEST
Still present xubuntu 16.04 LTS
Comment 27 Weedy 2016-08-24 01:08:47 CEST
So I kinda forgot this bug existed and ended up with Thunar eating about 20 gigs worth of stuff.

HOW is this bug such a low priority? We are nearing in on a year of this crap.
Comment 28 Derk te Bokkel 2016-08-24 14:24:59 CEST
testing .. thunar-gtk3 .. still shows this bug

triggered by moving files into a directory ..


(thunar:26727): GLib-GIO-CRITICAL **: g_dbus_proxy_call_finish_internal: assertion 'error == NULL || *error == NULL' failed
Segmentation fault (core dumped)

see bug .. 12772 for other thunar-gtk3 and exo-gtk3 test info
Comment 29 kafran 2016-09-08 10:01:51 CEST
This bug still exists on Xubuntu 16.04
Comment 30 Alejandro Perez 2016-09-08 10:19:20 CEST
This particular long-lasting bug made me switch to MATE. Very happy so far. I'm removing myself from being notified about this bug.
Comment 31 vc-01 2017-02-06 18:24:07 CET
Created attachment 6984 
[FIX] Unreference file object after callback function return

I found the core of this issue (and this bug is present also if moving one file):

 thunar_file_reload_idle (file);
 g_object_unref (file);

thunar_file_reload_idle() registers routine thunar_file_reload() to be run in idle. If object unreferencing in second line is run before this registered function (very likely), assertion for the file object in thunar_file_reload() fails and thunar crashes. 

I'm sending a patch where unreferencing is done in callback function called after thunar_file_reload().

Please tell me if any polishing for the patch is needed.

I added new function thunar_file_reload_idle_unref(), other option would be adding "callback after callback return" argument to thunar_file_reload_idle() or other approaches.
Comment 32 Simon Steinbeiss editbugs 2017-02-09 00:17:31 CET
Hi! Thanks for your effort to fix this bug!

Just a small comment (also since you asked for any polishing-related feedback): It would be nice if you could attach this as a real git patch instead of a diff, so maintainers can push it as is.
Comment 33 Mukundan Ragavan 2017-02-09 03:09:48 CET
Thanks for the fixes! 

One quick (and hopefully, last question) - is there going to be a new Thunar release with the latest commits?
Comment 34 vc-01 2017-02-09 11:34:54 CET
Created attachment 6988 
[PATCH] Fix object unreferencing

diff -> full git patch update
Comment 35 Alistair Buxton 2017-02-09 16:03:43 CET
#34 is definitely on to something. Setting up an async call on an object and then immediately unref'ing (which is also an async call) is bound to cause race conditions and random crashes like we see here.

I notice that the inline doc for thunar_file_reload says this:

"You must be able to handle the case that @file is destroyed during the reload call."

but the function itself has no such code to handle this case, and since @file can be destroyed at any point due to threading I don't see how it would even be possible to handle it without putting a mutex on @file.

Also I don't understand why it is necessary to reload the file immediately before unref'ing it. Why not just unref it immediately? There is probably a good reason for this that I'm just not seeing.

It would be a good idea for all developers to take a quick look at their code and make sure this "async reload/unref" anti-pattern is not showing up elsewhere.
Comment 36 flocculant 2017-02-09 20:06:49 CET
Copied 36Gb from a to b and c at the same time.

Deleted same from a. Moved from b to a. 

Deleted from c. Copied from a to b once more, copied 57Gb from c to a at the same time.

Copied 36Gb from b to c, while 57Gb was still copying from c to a.

Cleaned up to return to original position.

Redid this twice more.

No crashing.
Comment 37 Simon Steinbeiss editbugs 2017-02-09 20:32:16 CET
@Mukundan Ragavan: Yes, I'm basically waiting until we have reviewed and pushed enough patches (maybe this is already the last one for now) and then I will do another release.

@Alistair, flocculant: Thanks for reviewing and testing.
Comment 38 Simon Steinbeiss editbugs 2017-02-10 23:11:19 CET
Pushed to master:

Thanks for the patch, Vladimir!

Bug #12260

Reported by:
Michael Ropy
Reported on: 2015-10-14
Last modified on: 2017-02-10
Duplicates (1):
  • 12509 Thunar crashes when renaming file


Xfce Bug Triage
CC List:
26 users




Thunar Crash Report (22.20 KB, application/octet-stream)
2015-10-14 14:26 CEST , Michael Ropy
no flags
Debug session + backtrace (1.71 KB, text/plain)
2015-11-07 16:11 CET , flo.xfce
no flags
gdb debug output (24.69 KB, text/plain)
2015-11-09 16:02 CET , htd
no flags
GDB backtrace Thunar patched (3.11 KB, text/plain)
2015-11-10 07:42 CET , htd
no flags
Backtrace Thunar (24.38 KB, text/plain)
2015-11-11 07:23 CET , htd
no flags
[FIX] Unreference file object after callback function return (1.91 KB, patch)
2017-02-06 18:24 CET , vc-01
no flags
[PATCH] Fix object unreferencing (2.39 KB, patch)
2017-02-09 11:34 CET , vc-01
no flags

Additional information