If I drag a file into another folder Thunar crashes with following output: (thunar:10077): GLib-GIO-CRITICAL **: g_file_hash: assertion 'G_IS_FILE (file)' failed (thunar:10077): GLib-GIO-CRITICAL **: g_file_hash: assertion 'G_IS_FILE (file)' failed (thunar:10077): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed (thunar:10077): GLib-GIO-CRITICAL **: g_file_query_info: assertion 'G_IS_FILE (file)' failed (thunar:10077): GLib-GIO-CRITICAL **: g_file_get_basename: assertion 'G_IS_FILE (file)' failed Segmentation fault (core dumped) I'm running on ArchLinux with glib in version 2.45.2 (build from git) and gvfs in version 1.25.2 (also build from git). I have some packages which require these newer versions. I assume that the crash has something to do with glib. So can someone with glib 2.44 confirm this bug?
Best way of finding out is downgrading temporarily to 2.44 and try to reproduce. Using glib-2.44.1 here, no problems.
After downgrade I do not encounter the bug anymore.
Then probably it is a bug in the new glib, or at least caused by it. If you can do a git bisect of glib, this might help finding the offending commit: https://git.gnome.org/glib/
I just did the bisect, but without success. All builds worked fine. I installed the glib versions under test into /usr/local while still having a working glib (2.44) installed in /usr. Usually /usr/local is read first, I hope Thunar works the same way when requesting glib. It still could have something to do with the build configuration. I will have a look at the build configuration of the glib version which caused the bug.
Created attachment 6331 Valgrind Output when dragging a file to a new folder Just out of curiosity I ran thunar with valgrind and got the output in the attachment. This is the output of starting thunar and dragging one file to another folder. The interesing output starts at line 131.
The problem is not related to my build configuration I suppose. I ran tests with glib compiled with and without debug support. Both work fine in version 2.44 but not in version 2.45. I will try the bisect again but this time installing into /usr instead of /usr/local.
I confirm this is a problem with glib-2.45.x, but not with glib-2.44. Either something in the newer glib is faulty, or it is correct and triggers a yet undetected bug in thunar. Finding the offending commit via a git bisect could help pinpoint the issue; at the moment I simply do not have enough time for that. I recommend installing glib into /usr instead of /usr/local, as I assume your system thunar will look there for the libs. Alternatively, you can rebuild thunar into /usr/local too.
I ran a bisect again, this time installing into /usr and found the offending commit: 2737ab3201163631be152801a859b3874a667f10 Unfortunaly this is a huge commit. Is there a good way to find out which glib functions and their dependecies are used in Thunar and were changed in this commit? Btw: Removing files by pressing "del" also results in a crash and is also caused by this commit.
(In reply to flo.xfce from comment #8) > I ran a bisect again, this time installing into /usr and found the offending > commit: 2737ab3201163631be152801a859b3874a667f10 > Unfortunaly this is a huge commit. Is there a good way to find out which > glib functions and their dependecies are used in Thunar and were changed in > this commit? Right, a huge commit and especially bad for bisecting. Honestly, at the moment I do not really have an idea what could be causing this, though I have some suspicions - and I want to stress that these are only hazy suspicions - regarding the changes of the GFileMonitorSource stuff and how events are processed, though mutex locked. > Btw: Removing files by pressing "del" also results in a crash and is also > caused by this commit. These are good observations. What these issues have in common is that they are executed by thunar io jobs, and we have made changes to that in recent thunar versions to fix file information reload/update bugs. Maybe these somehow conflict with the new glib implementation. Again, these are only assumptions. Perhaps an older thunar version - 1.6.4 should be ok, later ones have other similar crash issues and hence are no good candidates for testing - is unaffected, though it will of course have the update/reload bugs.
I tested some snapshots and the bug seems to occur after 1.6.6. But I will recheck this again. For today I used my time to build Thunar 1.6.7 with full debug support and ran it with gdb: (thunar:22594): thunar-CRITICAL **: thunar_file_cache_lookup: assertion '(((__extension__ ({ GTypeInstance *__inst = (GTypeInstance*) ((file)); GType __t = ((g_file_get_type ())); gboolean __r; if (!__inst) __r = (0); else if (__inst->g_class && __inst->g_class->g_type == __t) __r = (!(0)); else __r = g_type_check_instance_is_a (__inst, __t); __r; }))))' failed [...] Program received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff4b51ceb in g_logv () from /usr/lib/libglib-2.0.so.0 My next move will be bisecting thunar, hopefulle someting useful will come up then.
Maybe http://git.xfce.org/xfce/thunar/commit/?id=3874e4e230a6a1de70444817b0804437a23b4d89. You could try to revert the changes to thunar-job.c done by this commit, keep the changes in thunar-file.c and apply http://git.xfce.org/xfce/thunar/commit/?id=9bf051a0005cef3d661493a44e7de911868cf5e7 (from thunar-1.6.10).
I am attaching a gdb backtrace: Program received signal SIGSEGV, Segmentation fault. 0x000000000043691a in thunar_file_info_reload (file=file@entry=0x7fffe0013580, cancellable=cancellable@entry=0x0) at thunar-file.c:975 975 thunar-file.c: Datei oder Verzeichnis nicht gefunden. (gdb) bt #0 0x000000000043691a in thunar_file_info_reload (file=file@entry=0x7fffe0013580, cancellable=cancellable@entry=0x0) at thunar-file.c:975 #1 0x0000000000436d81 in thunar_file_load (file=file@entry=0x7fffe0013580, error=error@entry=0x0, cancellable=0x0) at thunar-file.c:1177 #2 0x0000000000438a7b in thunar_file_get (gfile=gfile@entry=0x0, error=error@entry=0x0) at thunar-file.c:1236 #3 0x000000000043a1a7 in thunar_folder_monitor (monitor=<optimized out>, event_file=0xf57580, other_file=0x0, event_type=G_FILE_MONITOR_EVENT_MOVED, user_data=<optimized out>) at thunar-folder.c:776 #4 0x00007ffff0395f9e in ffi_call_unix64 () at /var/tmp/portage/dev-libs/libffi-3.2.1/work/libffi-3.2.1/src/x86/unix64.S:76 #5 0x00007ffff0395a08 in ffi_call (cif=cif@entry=0x7fffffffcde0, fn=0x439fc0 <thunar_folder_monitor>, rvalue=0x7fffffffcd00, avalue=avalue@entry=0x7fffffffcc60) at /var/tmp/portage/dev-libs/libffi-3.2.1/work/libffi-3.2.1/src/x86/ffi64.c:525 #6 0x00007ffff4e4c295 in g_cclosure_marshal_generic_va (closure=0xddba80, return_value=0x0, instance=0xf794b0, args_list=<optimized out>, marshal_data=0x0, n_params=3, param_types=0x71fd00) at /var/tmp/portage/dev-libs/glib-2.45.3/work/glib-2.45.3/gobject/gclosure.c:1594 #7 0x00007ffff4e4b827 in _g_closure_invoke_va (closure=closure@entry=0xddba80, return_value=return_value@entry=0x0, instance=instance@entry=0xf794b0, args=args@entry=0x7fffffffd028, n_params=3, param_types=0x71fd00) at /var/tmp/portage/dev-libs/glib-2.45.3/work/glib-2.45.3/gobject/gclosure.c:864 #8 0x00007ffff4e64748 in g_signal_emit_valist (instance=0xf794b0, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffd028) at /var/tmp/portage/dev-libs/glib-2.45.3/work/glib-2.45.3/gobject/gsignal.c:3246 #9 0x00007ffff4e6539a in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=detail@entry=0) at /var/tmp/portage/dev-libs/glib-2.45.3/work/glib-2.45.3/gobject/gsignal.c:3393 #10 0x00007ffff50e609b in g_file_monitor_emit_event (monitor=<optimized out>, child=<optimized out>, other_file=<optimized out>, event_type=<optimized out>) at /var/tmp/portage/dev-libs/glib-2.45.3/work/glib-2.45.3/gio/gfilemonitor.c:275 #11 0x00007ffff518abb9 in g_file_monitor_source_dispatch (source=0xed5a20, callback=<optimized out>, user_data=<optimized out>) at /var/tmp/portage/dev-libs/glib-2.45.3/work/glib-2.45.3/gio/glocalfilemonitor.c:546 #12 0x00007ffff4b4c914 in g_main_dispatch (context=0x6f69d0) at /var/tmp/portage/dev-libs/glib-2.45.3/work/glib-2.45.3/glib/gmain.c:3122 #13 g_main_context_dispatch (context=context@entry=0x6f69d0) at /var/tmp/portage/dev-libs/glib-2.45.3/work/glib-2.45.3/glib/gmain.c:3737 #14 0x00007ffff4b4cb68 in g_main_context_iterate (context=0x6f69d0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /var/tmp/portage/dev-libs/glib-2.45.3/work/glib-2.45.3/glib/gmain.c:3808 #15 0x00007ffff4b4ce2a in g_main_loop_run (loop=0xdaf1a0) at /var/tmp/portage/dev-libs/glib-2.45.3/work/glib-2.45.3/glib/gmain.c:4002 #16 0x00007ffff6a2ef17 in IA__gtk_main () at /var/tmp/portage/x11-libs/gtk+-2.24.28-r1/work/gtk+-2.24.28/gtk/gtkmain.c:1268 #17 0x000000000041ff2b in main (argc=1, argv=0x7fffffffd428) at main.c:312 Like cavalier recommended on IRC #xfce-dev, I will try to protect against the other_file == NULL cases. Maybe that fixes it. I'll upload a patch later.
Created attachment 6359 fix-crashes-when-reloading-target-file-after-move.patch This patch fixes the issue for me. It does not crash when deleting files (comment #8) - is this when moving files to the trash? Please test and report back.
I tested the patch with Thunar 1.6.10 and glib 2.45.3. It didn't crash anymore (deleting, moving, pasting). Reloading has some problems though (only when deleting). The deleted file is still visible. Changing a directory back and forth, pasting a file, deleting a second file, ... lets the deleted file disappear. Trying to delete this file a second time shows an error that this file does not exist (but this is intended behaviour). In rare cases, the deleted file disappears immediately (I would guess in 1 of 20 cases).
Does reverting http://git.xfce.org/xfce/thunar/commit/?id=98300e06651362af1075dd4bc263b9761b4a8b66 fix the delete problems?
No, reverting this commit does not solve the problem. To be precise: Files remaining visible only occures when deleting them by pressing "del". Right click->Delete works flawlessly.
I cannot reproduce the delete issue on my systems. Anyway, this is a different problem, so please open another bug report for it, though with current data I won't be able to do much for the reasons stated. Pushed to master: http://git.xfce.org/xfce/thunar/commit/?id=029012f4c39d9d3d9ae617491a69f76f54a4192f Since the original issue is fixed, I am closing this bug.