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://www.mail-archive.com/debian-bugs-dist@lists.debian.org/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 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 ~]#
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.
*** Bug 12509 has been marked as a duplicate of this bug. ***
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.
Still present xubuntu 16.04 LTS
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.
testing .. thunar-gtk3 .. still shows this bug triggered by moving files into a directory .. thunar (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
This bug still exists on Xubuntu 16.04
This particular long-lasting bug made me switch to MATE. Very happy so far. I'm removing myself from being notified about this bug.
Created attachment 6984 [FIX] Unreference file object after callback function return Hello. I found the core of this issue (and this bug is present also if moving one file): thunar-job.c:581 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.
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.
Thanks for the fixes! One quick (and hopefully, last question) - is there going to be a new Thunar release with the latest commits?
Created attachment 6988 [PATCH] Fix object unreferencing diff -> full git patch update
#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.
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.
@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.
Pushed to master: https://git.xfce.org/xfce/thunar/commit/?id=240a7f3b34694bb737ebbb9145b11bbc3e65553b Thanks for the patch, Vladimir!