Select a file. Ctrl+C to copy Ctrl+V to create the copy > THUNAR CRASH
Hi, Same problem here. This is the dmesg output: ------------------------------- [14614.191656] Thunar[1551]: segfault at 4 ip 00007f28d6ce7d80 sp 00007fff948effa8 error 6 in libdbus-1.so.3.7.6[7f28d6cc4000+44000] ------------------------------- Same error using context menu "Send to:" to an USB pendrive. Thanks!
Hello, I cannot reproduce the bug. Please provide as much information as possible about your system (name, version...) Did you compile Thunar from source ? Regards,
Hi, thunar installed from xubuntu-dev PPA Xubuntu 14.04.1 x86_64 Kernel: 3.18.0-031800-lowlatency $ apt-cache policy thunar thunar: Instalados: 1.6.4-0ubuntu1~14.04 Candidato: 1.6.4-0ubuntu1~14.04 Tabla de versión: *** 1.6.4-0ubuntu1~14.04 0 500 http://ppa.launchpad.net/xubuntu-dev/xfce-4.12/ubuntu/ trusty/main amd64 Packages 100 /var/lib/dpkg/status 1.6.3-1ubuntu5 0 500 http://es.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages $ apt-cache policy libdbus-1-3 libdbus-1-3: Instalados: 1.6.18-0ubuntu4.3 Candidato: 1.6.18-0ubuntu4.3 Tabla de versión: *** 1.6.18-0ubuntu4.3 0 500 http://es.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages 100 /var/lib/dpkg/status 1.6.18-0ubuntu4 0 500 http://es.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
Hi, I have the same bug one thunar 1.6.4 (I use the xubuntu-dev 4.12 PPA). I use Xubuntu 14.04 amd64 (fresh install). It doesn't crash at each copy pasting but it is 1/4 of the time ! Regards
A number of Fedora users are seeing this issue with 1.6.4 as well. See downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1183644 There's a number of backtraces in that bug or it's duplicates. Note that this seems to only be happening on Fedora 20, so perhaps there's a library version issue? dbus in f20: dbus-1.6.28-3.fc20 dbus in f21: dbus-1.8.14-1.fc21 Happy to ask for more info or try tests...
dbus version is 1.6.18 in trusty (14.04).
Thunar unpredictably crashes while a copy of a file with [Ctrl]_[C] – [Ctl]_[V] is made. The crash can happened when you try to copy a file from one Thunar window to another as well. I am using Fedora 20 x64. Thunar version: Thunar-1.6.4-1.fc20.x86_64 Downgrade to the previous version (1.6.3-2) solves the issue.
Bug can be reproduced with 'git master', gdb backtrace on LinuxMint 17.1 / Ubuntu 14.04 : #0 _dbus_watch_invalidate (watch=0x0) at ../../dbus/dbus-watch.c:171 #1 0x00007ffff54409cd in free_watches (transport=transport@entry=0x734d70) at ../../dbus/dbus-transport-socket.c:83 #2 0x00007ffff5440a39 in socket_disconnect (transport=0x734d70) at ../../dbus/dbus-transport-socket.c:1019 #3 0x00007ffff543fea7 in _dbus_transport_disconnect (transport=0x734d70) at ../../dbus/dbus-transport.c:509 #4 0x00007ffff5440675 in _dbus_transport_queue_messages (transport=0x734d70) at ../../dbus/dbus-transport.c:1165 #5 0x00007ffff5429539 in _dbus_connection_get_dispatch_status_unlocked (connection=0x735430) at ../../dbus/dbus-connection.c:4238 #6 0x00007ffff5429f86 in dbus_connection_get_dispatch_status (connection=0x735430) at ../../dbus/dbus-connection.c:4369 #7 0x00007ffff566dcc3 in message_queue_prepare (source=<optimized out>, timeout=timeout@entry=0x7fffffffdf94) at dbus-gmain.c:71 #8 0x00007ffff4b9a68d in g_main_context_prepare (context=context@entry=0x731fd0, priority=priority@entry=0x7fffffffe018) at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3352 #9 0x00007ffff4b9af03 in g_main_context_iterate (context=0x731fd0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3714 #10 0x00007ffff4b9b30a in g_main_loop_run (loop=0xaa3b00) at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3928 #11 0x00007ffff6a24447 in IA__gtk_main () at /build/buildd/gtk+2.0-2.24.23/gtk/gtkmain.c:1271 #12 0x000000000042065b in main (argc=1, argv=0x7fffffffe228) at main.c:310
In my case it never happens when working on local file systems, but always if I do try to copy files via smb:// or ssh:// I get this on GDB: (thunar:10959): Gdk-CRITICAL **: IA__gdk_window_get_window_type: assertion 'GDK_IS_WINDOW (window)' failed Program received signal SIGSEGV, Segmentation fault. 0x00007ffff5445d80 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
Sorry forgot to add, I'm running Xubuntu 14.04.1 with the xubuntu-dev PPA
I too can report this issue: Thunar 1.6.4 crashes when compying to/from USB keys. Since rendered effectively unusable, I downgraded to 1.6.3. Using Xubuntu 14.04 and 1.6.4 installed from the 4.12 PPA.
Cannot reproduce. Using extra/thunar 1.6.4-2 and core/libdbus 1.8.14-1 ArchLinux 64bits, Linux 3.18.4 Please if you have this bug, attach *all* the files in the folder where you can reproduce the bug, and give *exact* instructions (which file is copied and where is it copied).
For the backtrace, try to get down the trace to the _dbus_transport_queue_messages and further down and print all parameters and variables you can. This only happens with an older version of libdbus which I can't install. Thunar 1.6.4 changes how copied filenames are handled, which could cause a regression? Could the introduction of parentheses in the copied file filename trigger a hidden libdbus bug? See https://bugzilla.redhat.com/show_bug.cgi?id=1183644
Here we go: Thunar v1.6.4 from https://launchpad.net/~xubuntu-dev/+archive/ubuntu/xfce-4.12 libdbus-1-3 v1.6.18 Xubuntu 64bit geek@liv-inspiron:~$ uname -a Linux liv-inspiron 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux To reproduce: mkdir /tmp/asdf4 mkdir /tmp/asdf5 touch /tmp/asdf4/asdf.txt Then open the two folders in two tabs. Copy file and paste in other folder. Crash. Works like a charm here... And this is what I get on the command-line: process 19651: arguments to dbus_pending_call_unref() were incorrect, assertion "pending != NULL" failed in file ../../dbus/dbus-pending-call.c line 608. This is normally a bug in some application using the D-Bus library. Segmentation fault (core dumped)
Some more info. Apport reports: thunar crashed with SIGSEGV in dbus_message_get_reply_serial() Here's the report it has produced: http://s000.tinyupload.com/index.php?file_id=53378604583067631041 You can open it with Apport, it seems.
Would be great if one of you who can reproduce can bisect and identify the commit that introduced the regression in 1.6.4.
The only commit directly related to copying I could see when browsing git is this one: http://git.xfce.org/xfce/thunar/commit/?id=3d20b81250eddcd3df0b027478831b0f38817a1c
Simon, I have only approximate familiarity with git bisect. How can I bisect while omitting only this specific commit: http://git.xfce.org/xfce/thunar/commit/?id=3d20b81250eddcd3df0b027478831b0f38817a1c ? Thanks!
Bisecting and going back to that one commit are alternatives. So ideally what you can do is clone git master, then use "git checkout <sha1>" to check out a particular commit. I suggest you try the commit before the one I linked and with that commit itself too. That way you can check whether this would be the offending change. (Note: bisecting isn't terribly difficult, just RTFM or something like this: http://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git)
GIT bisect points me to this: 5bce93830d1005273a4af0fc45417418c671f28c is the first bad commit commit 5bce93830d1005273a4af0fc45417418c671f28c Author: Andre Miranda <andreldm1989@gmail.com> Date: Wed Dec 17 00:53:32 2014 -0300 Fix for bug 10864 - thunar incorrectly showing file sizes :040000 040000 0dfac981efff86bacadcad49df0a341b1a2bb7f5 06abadc95431cec956b1130b6d6efcd79e17bb42 M thunar
Is the GIT bisect useful, or would it help devels if I provided a gdb trace?
The problem with the traces is that the crash occurs later, in a different thread than the one where the copy is made (as you can see the backtrace stack contains no mention of thunar_ functions). I'll have to look at the patch you bisected in more details to determine what's useful to look at, but we would need you to add breakpoints in places to be determined. What could be useful would be to reproduce the crash with valgrind, just to make sure the bug doesn't cause memory corruptions (those would be harder to debug manually). Try: valgrind --leak-check=full thunar >/tmp/valgrind-log 2>&1 and attach the file /tmp/valgrind-log Thanks!
For valgrind, do I need to recompile Thunar with debugging symbols enabled?
Basically, do a first run with the normal Thunar and look at the report. Lookup for "Invalid read" and "Invalid write". Every time there is a memory error, Valgrind will add a trace of the functions that were being called when the error occurred. If you're missing debugging symbols for one library, you'll see a lot of "???". For instance, I just spotted an error in libcairo, so I'll install the debugging symbols of libcairo rather than Thunar.
OK, I installed all debugging packages that I could spot. Please advise if there are others that I need to install. http://s000.tinyupload.com/index.php?file_id=04996223041570123779 In the valgrind-log4 I see two instances of: valgrind-log4:62: ==31532== Invalid read of size 8 valgrind-log4:147: ==31532== Invalid read of size 8 Found 2 matches for "Invalid ". As a note, the crash is sometimes difficult to reproduce. That is, sometimes copying works fine, other times it crashes. It's more or less random...
I installed some additional debugging symbols. Here's what I think is a more complete version of the valgrind debug: http://s000.tinyupload.com/index.php?file_id=60273280179349243433 valgrind-log5:62: ==957== Invalid read of size 8 valgrind-log5:147: ==957== Invalid read of size 8 valgrind-log5:207: ==957== Invalid read of size 8 Found 3 matches for "Invalid ".
And for good measure a gdb trace: geek@liv-inspiron:~$ gdb thunar GNU gdb (Ubuntu 7.7-0ubuntu3) 7.7 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from thunar...Reading symbols from /usr/lib/debug/.build-id/7e/32b458faa818dfd7b90e73b285432feeed12c8.debug...done. done. (gdb) run Starting program: /usr/bin/thunar [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffedaec700 (LWP 1014)] [New Thread 0x7fffed2eb700 (LWP 1016)] [New Thread 0x7fffe4f7f700 (LWP 1018)] (thunar:1010): GLib-CRITICAL **: Source ID 169 was not found when attempting to remove it (thunar:1010): Gdk-CRITICAL **: IA__gdk_window_get_window_type: assertion 'GDK_IS_WINDOW (window)' failed (thunar:1010): GLib-CRITICAL **: Source ID 296 was not found when attempting to remove it Program received signal SIGSEGV, Segmentation fault. _dbus_watch_invalidate (watch=0x0) at ../../dbus/dbus-watch.c:171 171 ../../dbus/dbus-watch.c: No such file or directory. (gdb) bt #0 _dbus_watch_invalidate (watch=0x0) at ../../dbus/dbus-watch.c:171 #1 0x00007ffff54449cd in free_watches (transport=transport@entry=0x5555558495a0) at ../../dbus/dbus-transport-socket.c:83 #2 0x00007ffff5444a39 in socket_disconnect (transport=0x5555558495a0) at ../../dbus/dbus-transport-socket.c:1019 #3 0x00007ffff5443ea7 in _dbus_transport_disconnect (transport=0x5555558495a0) at ../../dbus/dbus-transport.c:509 #4 0x00007ffff5444675 in _dbus_transport_queue_messages (transport=0x5555558495a0) at ../../dbus/dbus-transport.c:1165 #5 0x00007ffff542d539 in _dbus_connection_get_dispatch_status_unlocked (connection=0x555555849c20) at ../../dbus/dbus-connection.c:4238 #6 0x00007ffff542df86 in dbus_connection_get_dispatch_status (connection=0x555555849c20) at ../../dbus/dbus-connection.c:4369 #7 0x00007ffff5671cc3 in message_queue_prepare (source=<optimized out>, timeout=timeout@entry=0x7fffffffdcb4) at dbus-gmain.c:71 #8 0x00007ffff4b9e68d in g_main_context_prepare (context=context@entry=0x5555558472f0, priority=priority@entry=0x7fffffffdd38) at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3352 #9 0x00007ffff4b9ef03 in g_main_context_iterate (context=0x5555558472f0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3714 #10 0x00007ffff4b9f30a in g_main_loop_run (loop=0x5555560ecb70) at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3928 #11 0x00007ffff6a28417 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #12 0x0000555555577809 in main (argc=1, argv=0x7fffffffdf48) at main.c:310 (gdb) quit A debugging session is active. Inferior 1 [process 1010] will be killed. Quit anyway? (y or n) y
And another one. For some reason the gdb traces are sometimes different: geek@liv-inspiron:~$ gdb thunar GNU gdb (Ubuntu 7.7-0ubuntu3) 7.7 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from thunar...Reading symbols from /usr/lib/debug/.build-id/7e/32b458faa818dfd7b90e73b285432feeed12c8.debug...done. done. (gdb) run Starting program: /usr/bin/thunar [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffedaec700 (LWP 1035)] [New Thread 0x7fffed2eb700 (LWP 1036)] [New Thread 0x7fffe4f7f700 (LWP 1038)] (thunar:1030): GLib-CRITICAL **: Source ID 174 was not found when attempting to remove it (thunar:1030): Gdk-CRITICAL **: IA__gdk_window_get_window_type: assertion 'GDK_IS_WINDOW (window)' failed (thunar:1030): GLib-CRITICAL **: Source ID 282 was not found when attempting to remove it Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe4f7f700 (LWP 1038)] _dbus_watch_invalidate (watch=0x0) at ../../dbus/dbus-watch.c:171 171 ../../dbus/dbus-watch.c: No such file or directory. (gdb) bt #0 _dbus_watch_invalidate (watch=0x0) at ../../dbus/dbus-watch.c:171 #1 0x00007ffff54449cd in free_watches (transport=transport@entry=0x5555558495e0) at ../../dbus/dbus-transport-socket.c:83 #2 0x00007ffff5444a39 in socket_disconnect (transport=0x5555558495e0) at ../../dbus/dbus-transport-socket.c:1019 #3 0x00007ffff5443ea7 in _dbus_transport_disconnect (transport=0x5555558495e0) at ../../dbus/dbus-transport.c:509 #4 0x00007ffff5444675 in _dbus_transport_queue_messages (transport=transport@entry=0x5555558495e0) at ../../dbus/dbus-transport.c:1165 #5 0x00007ffff5444fae in do_reading (transport=0x5555558495e0) at ../../dbus/dbus-transport-socket.c:883 #6 0x00007ffff5445666 in socket_do_iteration (transport=0x5555558495e0, flags=6, timeout_milliseconds=<optimized out>) at ../../dbus/dbus-transport-socket.c:1194 #7 0x00007ffff54443ff in _dbus_transport_do_iteration (transport=0x5555558495e0, flags=0, flags@entry=6, timeout_milliseconds=1434736368, timeout_milliseconds@entry=25000) at ../../dbus/dbus-transport.c:976 #8 0x00007ffff542e9fc in _dbus_connection_do_iteration_unlocked (connection=connection@entry=0x555555849c60, pending=pending@entry=0x7fffcc010460, flags=flags@entry=6, timeout_milliseconds=timeout_milliseconds@entry=25000) at ../../dbus/dbus-connection.c:1234 #9 0x00007ffff542f3a9 in _dbus_connection_block_pending_call (pending=pending@entry=0x7fffcc010460) at ../../dbus/dbus-connection.c:2415 #10 0x00007ffff543e79a in dbus_pending_call_block (pending=pending@entry=0x7fffcc010460) at ../../dbus/dbus-pending-call.c:748 #11 0x00007ffff56778c4 in dbus_g_proxy_end_call_internal (proxy=proxy@entry=0x555555830b70, call_id=call_id@entry=64, error=error@entry=0x7fffe4f7e758, first_arg_type=93824995154368, args=args@entry=0x7fffe4f7e5d8) at dbus-gproxy.c:2399 #12 0x00007ffff567a829 in dbus_g_proxy_call (proxy=proxy@entry=0x555555830b70, method=method@entry=0x7ffff589b36a "GetProperty", error=error@entry=0x7fffe4f7e758, first_arg_type=<optimized out>, first_arg_type@entry=64) at dbus-gproxy.c:2764 #13 0x00007ffff5894605 in xfconf_client_get_property (error=0x7fffe4f7e758, OUT_value=0x7fffe4f7e760, IN_property=0x7fffe4f7e8e0 "/misc-file-size-binary", IN_channel=0x555555852f80 "thunar", proxy=0x555555830b70) at xfconf-dbus-bindings.h:69 #14 xfconf_cache_lookup_locked (cache=cache@entry=0x555555852190, property=property@entry=0x7fffe4f7e8e0 "/misc-file-size-binary", value=value@entry=0x7fffe4f7e860, error=error@entry=0x0) at xfconf-cache.c:670 #15 0x00007ffff5894dfe in xfconf_cache_lookup (cache=0x555555852190, property=property@entry=0x7fffe4f7e8e0 "/misc-file-size-binary", value=value@entry=0x7fffe4f7e860, error=error@entry=0x0) at xfconf-cache.c:714 #16 0x00007ffff5895325 in xfconf_channel_get_internal (channel=channel@entry=0x555555853800, property=property@entry=0x7fffe4f7e8e0 "/misc-file-size-binary", value=value@entry=0x7fffe4f7e860) at xfconf-channel.c:440 #17 0x00007ffff5896c96 in IA__xfconf_channel_get_property (channel=0x555555853800, property=property@entry=0x7fffe4f7e8e0 "/misc-file-size-binary", value=value@entry=0x7fffe4f7e8c0) at xfconf-channel.c:1258 #18 0x00005555555ae06f in thunar_preferences_get_property (object=<optimized out>, prop_id=<optimized out>, value=0x7fffe4f7e970, pspec=0x555555851350) at thunar-preferences.c:821 #19 0x00007ffff4e76005 in object_get_property (value=0x7fffe4f7e970, pspec=<optimized out>, object=0x555555831390) at /build/buildd/glib2.0-2.40.2/./gobject/gobject.c:1315 #20 g_object_get_valist (object=object@entry=0x555555831390, first_property_name=first_property_name@entry=0x5555555df444 "misc-file-size-binary", var_args=var_args@entry=0x7fffe4f7ea18) at /build/buildd/glib2.0-2.40.2/./gobject/gobject.c:2171 #21 0x00007ffff4e76497 in g_object_get (_object=_object@entry=0x555555831390, first_property_name=first_property_name@entry=0x5555555df444 "misc-file-size-binary") at /build/buildd/glib2.0-2.40.2/./gobject/gobject.c:2261 #22 0x00005555555cd265 in thunar_transfer_job_veryify_destination (error=0x7fffe4f7eb70, transfer_job=0x555556268160) at thunar-transfer-job.c:690 #23 thunar_transfer_job_execute (job=0x555556268160, error=0x7fffe4f7ebc8) at thunar-transfer-job.c:957 #24 0x00007ffff79aff60 in exo_job_scheduler_job_func (scheduler_job=0x555556153400, cancellable=<optimized out>, user_data=<optimized out>) at exo-job.c:317 #25 0x00007ffff510d4e6 in io_job_thread (task=<optimized out>, source_object=<optimized out>, task_data=0x555556153400, cancellable=<optimized out>) at /build/buildd/glib2.0-2.40.2/./gio/gioscheduler.c:85 #26 0x00007ffff5130065 in g_task_thread_pool_thread (thread_data=0x5555562681e0, pool_data=<optimized out>) at /build/buildd/glib2.0-2.40.2/./gio/gtask.c:1213 #27 0x00007ffff4bc488c in g_thread_pool_thread_proxy (data=<optimized out>) at /build/buildd/glib2.0-2.40.2/./glib/gthreadpool.c:307 #28 0x00007ffff4bc3f05 in g_thread_proxy (data=0x5555560d2a30) at /build/buildd/glib2.0-2.40.2/./glib/gthread.c:764 #29 0x00007ffff4940182 in start_thread (arg=0x7fffe4f7f700) at pthread_create.c:312 ---Type <return> to continue, or q <return> to quit--- #30 0x00007ffff466d30d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 (gdb) quit A debugging session is active. Inferior 1 [process 1030] will be killed. Quit anyway? (y or n) y
Thanks for the traces! A couple of things we could check from here: 1. Do you still have crashes when you uninstall thunar-vcs-plugin? 2. Any chance you make traces with thunar-vcs-plugin debugging symbols? I see some errors in the plugin but am missing the actual code lines. Then get back to me. If it turns out to be unrelated to the vcs plugin then I'll give you a patch to apply, that gives extra debug information. Thanks again for your help :-)
Crash still here with the vcs plugin uninstalled: Reading symbols from thunar...Reading symbols from /usr/lib/debug/.build-id/7e/32b458faa818dfd7b90e73b285432feeed12c8.debug...done. done. (gdb) run Starting program: /usr/bin/thunar [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffedaec700 (LWP 20973)] [New Thread 0x7fffed2eb700 (LWP 20974)] [New Thread 0x7fffe4f82700 (LWP 20976)] (thunar:20969): GLib-CRITICAL **: Source ID 175 was not found when attempting to remove it (thunar:20969): Gdk-CRITICAL **: IA__gdk_window_get_window_type: assertion 'GDK_IS_WINDOW (window)' failed (thunar:20969): GLib-CRITICAL **: Source ID 315 was not found when attempting to remove it Program received signal SIGSEGV, Segmentation fault. __memmove_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1544 1544 ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S: No such file or directory. (gdb) bt #0 __memmove_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1544 #1 0x00007ffff544941d in memmove (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string3.h:57 #2 delete (start=start@entry=0, len=len@entry=218, real=<optimized out>, real=<optimized out>) at ../../dbus/dbus-string.c:1183 #3 0x00007ffff5449d00 in delete (real=real@entry=0x555555849738, real=real@entry=0x555555849738, len=len@entry=218, start=start@entry=0) at ../../dbus/dbus-string.c:1201 #4 _dbus_string_delete (str=str@entry=0x555555849738, start=start@entry=0, len=len@entry=218) at ../../dbus/dbus-string.c:1208 #5 0x00007ffff543c68d in load_message (body_len=82, header_len=136, fields_array_len=<optimized out>, byte_order=108, message=0x5555561d6460, loader=0x555555849730) at ../../dbus/dbus-message.c:4178 #6 _dbus_message_loader_queue_messages (loader=0x555555849730) at ../../dbus/dbus-message.c:4252 #7 0x00007ffff5444520 in _dbus_transport_get_dispatch_status ( transport=transport@entry=0x5555558495a0) at ../../dbus/dbus-transport.c:1101 #8 0x00007ffff5444653 in _dbus_transport_queue_messages (transport=0x5555558495a0) at ../../dbus/dbus-transport.c:1128 ---Type <return> to continue, or q <return> to quit--- #9 0x00007ffff542d539 in _dbus_connection_get_dispatch_status_unlocked ( connection=0x555555849c20) at ../../dbus/dbus-connection.c:4238 #10 0x00007ffff542df86 in dbus_connection_get_dispatch_status (connection=0x555555849c20) at ../../dbus/dbus-connection.c:4369 #11 0x00007ffff5671cc3 in message_queue_prepare (source=<optimized out>, timeout=timeout@entry=0x7fffffffdcb4) at dbus-gmain.c:71 #12 0x00007ffff4b9e68d in g_main_context_prepare (context=context@entry=0x5555558472f0, priority=priority@entry=0x7fffffffdd38) at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3352 #13 0x00007ffff4b9ef03 in g_main_context_iterate (context=0x5555558472f0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3714 #14 0x00007ffff4b9f30a in g_main_loop_run (loop=0x5555560efb00) at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3928 #15 0x00007ffff6a28417 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #16 0x0000555555577809 in main (argc=1, argv=0x7fffffffdf48) at main.c:310
And I no longer notice any invalid issues with valgrind: http://s000.tinyupload.com/index.php?file_id=10601574138842540715 I think the VCS plugin is only incidental to the crashes, as now it's not installed...
It crashes without thunar-vcs-plugin installed. thunar-vcs-plugin has made trouble time to time but this is not the case. (Fedora 20 x64 Thunar-1.6.4-1.fc20.x86_64)
For info, I keep getting copy-related crashes in 1.6.5.
@Liviu Andronic, I use Thunar built from git sources with debugging enabled, not the Xubuntu PPA, and I cannot reproduce this bug. I've seen it once only. I will set up a virtual machine with Xubuntu 14.04 and build all Xfce4 core components from git master with debugging enabled in order to see if I can reproduce it. Could you do the same ? (https://github.com/LinuxMatt/xfce4-builder may help you)
As mentioned in https://bugzilla.xfce.org/show_bug.cgi?id=11450#c20 , I did a GIT bisect using default configure options (debugging disabled), and identified the commit. Which means I was able to regularly reproduce the bug by building GIT from source (NOT using the PPA). Would it help if I compiled 5bce93830d1005273a4af0fc45417418c671f28c with debugging enabled and provided a gdb trace?
@Liviu Andronic, I have set up a Virtualbox machine and installed Xubuntu 14.04.1 64 bits. I installed all the Xubuntu updates with update-manager. Then I built Xfce from git master with xfce4-builder. Then I used the .xinitrc from xfce4-builder to start a second X session. I still cannot reproduce the bug that you have in comment 14. Could you do the same ?
I'm sorry, I don't think I'll go as far as setting up a dedicated VM for this. Concerning the bug, sometimes you need to be patient as the bug may not manifest itself immediately. To reproduce, I sometimes need to redo the copy/paste operation 5-10 times before it finally hits a brick and crashes. Other times 2-3 retries suffices. And sometimes it's instantaneous.
I too do not experience any crashes here. Aside from dbus, could the glib version used have any influence here? sys-apps/dbus-1.8.16 dev-libs/dbus-glib-0.102 dev-libs/glib-2.42.1 x11-libs/gtk+-2.24.26
On my Ubuntu 14.04 LTS system: dbus-1.6.18 dbus-glib-0.100.2 glib-2.40.2 gtk+-2.24.23
Liviu, unfortunately simply reporting your versions here won't really help. I only gave them as references, but I _cannot_ reproduce the bug. Please update your dependencies, *one by one* and try to reproduce the issue. Make sure you spend enough time to be sure that it is really the component you updated.
I thought it was a good time to re-enable the dev PPA and see if thunar 1.65 solved the crashing bug for me. Unfortunately, it is still present for me. I used terminal windows to start two instances of thunar and then tried to move a file between them. The file is moved but both windows crash. The output in terminal window 1 was: (thunar:3495): GLib-CRITICAL **: Source ID 177 was not found when attempting to remove it (thunar:3495): GLib-CRITICAL **: Source ID 695 was not found when attempting to remove it (thunar:3495): GLib-CRITICAL **: Source ID 794 was not found when attempting to remove it (thunar:3495): GLib-CRITICAL **: Source ID 832 was not found when attempting to remove it (thunar:3495): GLib-CRITICAL **: Source ID 878 was not found when attempting to remove it (thunar:3495): GLib-CRITICAL **: Source ID 924 was not found when attempting to remove it and for terminal window 2: (thunar:3541): GLib-CRITICAL **: Source ID 165 was not found when attempting to remove it (thunar:3541): GLib-CRITICAL **: Source ID 431 was not found when attempting to remove it Segmentation fault
I seem to have resolved the problem on my pc. 1. I removed thunar 1.65 and let synaptic remove all the associated dependencies along with it. 2. Then I disabled the dev ppa and refreshed synaptic's lists. 3. Next I renabled the dev ppa and refreshed the lists again. 4. then I selected thunar 1.65 and let it synaptic include the dependencies. 5. finally, I added any of the other files from step 1 that were not re-added automatically in step 4. So it seems to me that in my case the problem was associated with the repo and the way the newer version and its dependencies were upgraded rather than bugs in thunar per se. Perhaps someone else experiencing the same crashes can try what I did above and report back on whether it helped them too.
OK, more testing and the crashing bug is still present. Just that now it is intermittent.
I too have been experiencing this bug. When I first noticed this bug, I was running Linux Mint 15 XFCE edition. I added the XFCE team repos, which let me update from Thunar 1.6.3 to Thunar 1.6.4. I noticed the crashing problem soon and it occured frequently. I somehow managed to roll back to Thunar 1.6.3 and the problem disappeared. I left the repo enabled and just unchecked Thunar updates every time. Last weekend, I updated to Mint 15.1 XFCE edition. Somehow, Thunar got updated to 1.6.5 in the process. I didn't notice the bug initially, but after a couple days, sure enough, the same behavior. dmesg says: [ 931.756420] Thunar[6947]: segfault at 4 ip 00007f780bc0bd80 sp 00007fffba5f7638 error 6 in libdbus-1.so.3.7.6[7f780bbe8000+44000] [ 2253.103787] Thunar[10196]: segfault at 7f68ce7bd000 ip 00007f68c89aa7a4 sp 00007fff072e0258 error 4 in libc-2.19.so[7f68c8860000+1bb000] Usually, the copy/paste operation still completes successfully. It doesn't only happen with a hotkey Ctrl+C/V -- even a drag/drop can trigger it. It seems to happen more often on removable drives. I just tried to revert back to Thunar 1.6.3 and was not able to do so successfully -- I got stuck in a held/broken packages situation that I was not able to resolve as I was previously. So now it seems I'm stuck with Thunar 1.6.5. I am happy to provide any logs or dumps that would help in tracking down this bug, but I don't know how to contribute meaningful bug reports on Linux. I will need instructions to do so. I am comfortable with a CLI, but I've only recently made Linux my primary OS. Thanks!
I had to do a ppa-purge to completely remove the dev ppa. That puts everything back to the stable xubuntu 14.04 versions successfully. I was about to try Linux Mint Xfce to see if that was a solution but now I know not to try. And if it is happening for a clean installs, the likelihood that using the recent 14.04.2 image is going to produce the same problems.
(In reply to slumbergod from comment #45) > I had to do a ppa-purge to completely remove the dev ppa. That puts > everything back to the stable xubuntu 14.04 versions successfully. > > I was about to try Linux Mint Xfce to see if that was a solution but now I > know not to try. > > And if it is happening for a clean installs, the likelihood that using the > recent 14.04.2 image is going to produce the same problems. I can't guarantee that it's happening for clean installs. I did an upgrade-in-place, and I don't know if the XFCE repo was still enabled before this happened. Give it a shot in a VM if you feel like trying.
Now that the packages in the dev PPA have been updated to 4.12 I wanted to try upgrading again. The very first action I tried in thunar was moving a text file from one thunar window to another with the mouse. Crash. After purging the dev repo again, I repeated the action with thunar 1.63. Worked correctly, no crash. Did the updated packages fix this issue for anyone else that was experiencing the crashing issue? Am I the only one?
Not immediately, but the crash is there alright in 1.6.6, too. Also using the Ubuntu PPA.
slumbergod, can you bisect too to confirm the other bisect? Also, does it help to revert the already bisected commit in 1.6.6?
And third, does this also happen in non-daemon mode? That is, kill any thunar instances and then launch a single instance *without* --daemon.
I'm affected, too. LM17.1 XFCE with Ubuntu PPA, Thunar v1.6.6
(In reply to Harald Judt from comment #50) > And third, does this also happen in non-daemon mode? That is, kill any > thunar instances and then launch a single instance *without* --daemon. It also happens when the daemon is not launched. "ps -A | grep unar" just shows Thunar (non daemon) as running process. BTW: There's also a thread to that topic on the xfce-forum (although probably not extremely helpful I have to admit): https://forum.xfce.org/viewtopic.php?id=9365
Not really helpful the thread... That's my output with normal thunar from terminal ;) process 7614: arguments to dbus_message_get_reply_serial() were incorrect, assertion "message != NULL" failed in file ../../dbus/dbus-message.c line 1090. This is normally a bug in some application using the D-Bus library. Segmentation fault
I have experienced a (not always reproducible) crash when moving files _via drag&drop_. Investigating that. But there are no dbus error messages at all, so this is probably a different bug.
@Harald Same bug, probably. I've experienced these crashes when ctrl+c/ctrl+v or when DnD'ing files. I can't say if I always get messages in the terminal, but I do see the crashes. It's not always reliably reproducible, but it shall manifest sooner rather than later in a given day.
@Harald "Also, does it help to revert the already bisected commit in 1.6.6?" What do you mean by that? How could I do this?
(In reply to Liviu Andronic from comment #56) > @Harald > > "Also, does it help to revert the already bisected commit in 1.6.6?" > > What do you mean by that? How could I do this? Clone thunar from git, type git revert 5bce93830d1005273a4af0f, hope that you don't have to do manual work to revert it, then build thunar. If you bisect and thunar doesn't build with a certain commit, you can use git bisect skip btw. man git-bisect gives you a nice documentation.
This is happing a -lot- with 1.6.6 today. More often than not, operations from a SD card to a local hard drive are crashing. If someone would please be kind enough to point me to a script or something I can run to generate a meaningful bug report -- I'm happy to submit a dozen, if it will help. I am not a developer, doing a git-bisect is out of my league, and I'm not really interested in learning the ins and outs of git just to help squash this bug. Otherwise, I'm going to have to switch to Nautilus temporarily, which I'm really not eager to do again.
Just an idea: the fact that the preferences are accessed from another thread during the copy/move operation, could it explain the crash ?
I tried the revert, but it didn't work out on master. >git checkout master (17188) Already on 'master' Your branch is up-to-date with 'origin/master'. >git checkout master (17188) returned '0' >git revert 5bce93830d1005273a4af0f (17191) error: could not revert 5bce938... Fix for bug 10864 - thunar incorrectly showing file sizes hint: after resolving the conflicts, mark the corrected paths hint: with 'git add <paths>' or 'git rm <paths>' hint: and commit the result with 'git commit' >git revert 5bce93830d1005273a4af0f (17191) returned '1' I don't know how to fix this, so if someone could provide a patch that applies to current GIT, I could try that out.
(In reply to Harald Judt from comment #50) > And third, does this also happen in non-daemon mode? That is, kill any > thunar instances and then launch a single instance *without* --daemon. I tried this, and the crash worked like a charm in 1.6.6: geek@liv-inspiron:~$ ps -A | grep unar 2269 ? 00:00:00 Thunar geek@liv-inspiron:~$ killall Thunar geek@liv-inspiron:~$ ps -A | grep unar geek@liv-inspiron:~$ Thunar (Thunar:17215): Gdk-CRITICAL **: IA__gdk_window_get_window_type: assertion 'GDK_IS_WINDOW (window)' failed (Thunar:17215): Gdk-CRITICAL **: IA__gdk_window_get_window_type: assertion 'GDK_IS_WINDOW (window)' failed Segmentation fault (core dumped)
Reverting that commit is not trivial at all, and I gave up. On another note, has anyone been able to reproduce this using dbus-1.8.x? It appears that all of the incidents of this bug have occurred on dbus-1.6.x.
(In reply to Harald Judt from comment #49) > slumbergod, can you bisect too to confirm the other bisect? Also, does it > help to revert the already bisected commit in 1.6.6? Sorry, I wouldn't have a clue how to do that. If I had more skills in that area I would be doing all I can to help resolve this.
This is odd. I can reliably reproduce this (i.e. EVERY copy/paste crashes thunar) on one machine but not another with the same package versions of everything :/ I'm trying to upgrade various pieces of the underlying system one at a time to see if I can narrow down some culprits. I've presently ruled out glib (upgraded from 2.36.4 to 2.42.2) and gtk (upgraded from 2.24.20 to 2.24.27). I'm about to look into dbus (currently 1.6.12) and dbus-glib (currently 0.100.2). * Well, I waited to post this, and it seems that after upgrading from dbus 1.6.12 to 1.6.18, I can no longer reproduce this.
Created attachment 6041 dbus patch Looks like this is caused by https://bugs.freedesktop.org/show_bug.cgi?id=66300 which was fixed in dbus-1.6.14 with this git commit f023c0e265443e8caab45aa9aa18ce245aa22af0 I'm not going to close this without some independent confirmation, but I'm attaching the patch to apply to dbus.
(In reply to Robby Workman from comment #65) > Created attachment 6041 > dbus patch > > Looks like this is caused by > https://bugs.freedesktop.org/show_bug.cgi?id=66300 which was fixed in > dbus-1.6.14 with this git commit f023c0e265443e8caab45aa9aa18ce245aa22af0 > Yes, but what was introduced in Thunar between 1.6.3 and 1.6.4 to make this bug manifest itself so violently?
It's almost surely the commit that was blamed, but why, I don't know.
I am running dbus 1.6.18-0ubuntu4.3 and still get these problems!
I am running dbus 1.6.30 Fedora 20 x64 and still get these problems!
OK, then there clearly is an obscure implementation defect that is causing all this. Recently many Xfce projects were submitted for audit using Coverity, a code checking tool: https://scan.coverity.com/projects?utf8=%E2%9C%93&search=xfce If there are no objections, I'll go ahead and submit Thunar code to this tool. Perhaps it will allow tracking down this frustrating occurrence.
Well, it's possible that there are multiple bugs here then. What I saw was this: Copy/paste crashes *EVERY* time on Thunar-1.6.6 with dbus-1.6.12. Copy/paste does not crash on Thunar-1.6.6 with dbus-1.6.14 (or 1.6.12 with the attached patch). It's certainly possible that I didn't try enough attempts and that it would have continued to crash *sometimes* - I'll look into that more over the weekend. Even so, given that I am *completely* unable to reproduce this using dbus-1.8.x (and I think the same is true for everyone else on dbus-1.8.x), I think it's pretty safe to say that this is somehow related to libdbus. Now the fun begins...
I just checked the version of dbus on my laptop. I have 1.6.18 but I have had crashing in all three recent versions of thunar so there must me more to it that just dbus.
recent = 1.8.x or latest 1.6.x -- that's (likely) important. It seems as if there are two (or more) actual bugs here, which is supported by the two different backtraces in this bug: 1) thunar crashes on *every* copy/paste operation 2) thunar crashes *sometimes* on copy/paste operation The thunar commit that *appears* to be at fault looks correct, according to the committer and some independent review, so it's (likely) exposing a problem elsewhere. I'm hoping to get some time this weekend to do the following: 1) confirm that the blamed commit is actually at fault 2) assuming #1, confirm that the dbus fixed mentioned earlier fixes the first apparent bug 3) also assuming #1, figure out whether something changed between dbus-1.6.x and 1.8.x to fix the second apparent bug I'm hoping to glean something useful from dbus-monitor output, but as with most things, it will require a bit of luck probably :-)
Early stages of debugging here; there may be lots of noise for a bit, but I'll try to condense stuff as best I can. Back to dbus 1.6.12 vanilla, dbus-glib 0.100.2, glib2 2.36.4, gtk+2 2.24.20 It seems more difficult to make Thunar crash with a dbus-monitor instance running in terminal, but I was finally able to get a crash with it (it took >10 tries). Here's the output in that terminal: method call sender=:1.59 -> dest=org.xfce.Xfconf serial=68 path=/org/xfce/Xfconf; interface=org.xfce.Xfconf; member=GetProperty string "thunar" string "/misc-full-path-in-title" error sender=:1.1 -> dest=:1.59 error_name=org.xfce.Xfconf.Error.PropertyNotFound reply_serial=68 string "Property "/misc-full-path-in-title" does not exist on channel "thunar"" method call sender=:1.59 -> dest=org.xfce.Xfconf serial=69 path=/org/xfce/Xfconf; interface=org.xfce.Xfconf; member=GetProperty string "thunar" string "/misc-file-size-binary" error sender=:1.1 -> dest=:1.59 error_name=org.xfce.Xfconf.Error.PropertyNotFound reply_serial=69 string "Property "/misc-file-size-binary" does not exist on channel "thunar"" signal sender=org.freedesktop.DBus -> dest=(null destination) serial=10 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Nam eOwnerChanged string "org.xfce.FileManager" string ":1.59" string "" signal sender=org.freedesktop.DBus -> dest=(null destination) serial=72 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Nam eOwnerChanged string "org.xfce.Thunar" string ":1.59" string "" signal sender=org.freedesktop.DBus -> dest=(null destination) serial=73 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Nam eOwnerChanged string ":1.59" string ":1.59" string "" signal sender=org.freedesktop.DBus -> dest=(null destination) serial=27 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Nam eOwnerChanged string ":1.60" string ":1.60" string "" method call sender=:1.34 -> dest=org.freedesktop.DBus serial=35 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus' ,arg0=':1.60'" method call sender=:1.33 -> dest=org.freedesktop.DBus serial=35 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus' ,arg0=':1.60'" method call sender=:1.32 -> dest=org.freedesktop.DBus serial=40 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus' ,arg0=':1.60'" signal sender=org.freedesktop.DBus -> dest=(null destination) serial=74 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Nam eOwnerChanged string ":1.65" string "" string ":1.65" method call sender=:1.65 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello method call sender=:1.65 -> dest=org.xfce.Terminal5 serial=2 path=/org/xfce/Terminal; interface=org.xfce.Terminal5; member=Launch uint32 1000 array of bytes [ 3a 30 00 ] array [ array of bytes [ 2f 75 73 72 2f 62 69 6e 2f 78 66 63 65 34 2d 74 65 72 6d 69 6e 61 6c 00 ] array of bytes [ 2d 2d 64 65 66 61 75 6c 74 2d 77 6f 72 6b 69 6e 67 2d 64 69 72 65 63 74 6f 72 79 00 ] array of bytes [ 2f 68 6f 6d 65 2f 72 77 6f 72 6b 6d 61 6e 00 ] array of bytes [ 2d 2d 73 74 61 72 74 75 70 2d 69 64 3d 78 66 63 65 34 2d 70 61 6e 65 6c 2f 65 78 6f 2d 6f 70 65 6e 2f 32 31 34 31 35 2d 33 2d 70 6b 67 64 65 76 36 34 5f 54 49 4d 45 32 37 34 38 36 33 37 00 ] array of bytes [ 2d 2d 64 65 66 61 75 6c 74 2d 64 69 73 70 6c 61 79 3d 3a 30 2e 30 00 ] ] method return sender=:1.62 -> dest=:1.65 reply_serial=2 signal sender=org.freedesktop.DBus -> dest=(null destination) serial=75 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Nam eOwnerChanged string ":1.65" string ":1.65" string ""
Created attachment 6045 Fix? Please review/test
(In reply to Robby Workman from comment #75) > Fix? > > Please review/test Fails! More info including my test-/buildcase can be found here: [1] https://bugzilla.redhat.com/show_bug.cgi?id=1183644#c57
I believe I found the problem! AND a solution. Even I was able to track the "problem" down to SHA1 5bce93830d1005273a4af0fc45417418c671f28c http://git.xfce.org/xfce/thunar/commit/?id=5bce93830d1005273a4af0fc45417418c671f28c The code looks ok to me. But what happens ? Here an attempt to explain. Everyone ran Thunar 1.6.3 before. Then Thunar 1.6.4 came up and everyone simply upgraded it. People continued using Thunar 1.6.4 as is. No further changes made to settings. The crash shows up once people copy stuff from A to B. But! There was this new option introduced in Thunar 1.6.4 in preferences saying "Show file size in binary format" This is by default set to "off" (unselected)... But internally when code executes the condition is how ? This causes the crashes. The initial condition is unknown. Once I selected this setting then I won't get any crashes anymore. After that you can unselect this setting again to set it's state to "off" and even then all crashes are gone. Please test and report back if select to "on/off" solved the issues.
After running a couple of tests some more feedback: I killed all Thunar processes and removed the thunar.xml in the xfce4 config directory. Same happens again. Crashes after a few copies. Some went good, others failed and crashed. Then I re-installed my old thunar.xml file from 1.6.3. The same happens once I ran 1.6.4 using that config file. What I noticed was, that: <property name="misc-file-size-binary" type="bool" value="false"/> Was missing in the file. Even under 1.6.4 if you don't go at least for once in the preferences, this property will not be set (at least here on my system). If not set (line missing entirely) the crashes show up. Once the property is written (regardles whether true or false), no crashes anymore.
Here a closer look at the problem and the ouput as posted here: https://bugzilla.xfce.org/show_bug.cgi?id=11450#c74 Which by the way affects other properties as well: method call sender=:1.59 -> dest=org.xfce.Xfconf serial=68 path=/org/xfce/Xfconf; interface=org.xfce.Xfconf; member=GetProperty string "thunar" string "/misc-full-path-in-title" error sender=:1.1 -> dest=:1.59 error_name=org.xfce.Xfconf.Error.PropertyNotFound reply_serial=68 string "Property "/misc-full-path-in-title" does not exist on channel "thunar"" Error: Property not found "misc-full-path-in-title". So what should thunar do in this case ? method call sender=:1.59 -> dest=org.xfce.Xfconf serial=69 path=/org/xfce/Xfconf; interface=org.xfce.Xfconf; member=GetProperty string "thunar" string "/misc-file-size-binary" error sender=:1.1 -> dest=:1.59 error_name=org.xfce.Xfconf.Error.PropertyNotFound reply_serial=69 string "Property "/misc-file-size-binary" does not exist on channel "thunar"" Error: Property not found "misc-file-size-binary". So what thunar does is randomly crashing.
(In reply to Ali Akcaagac from comment #77) > Please test and report back if select to "on/off" solved the issues. Looks like a good candidate. I did the above, and I don't seem to be getting crashes.
Hi, I try the on/off setting and it seems to work.
Trying to get this together. I deal with Thunar sources for the first time today. So please apologizes. Here my thoughts. 1) Thunar has an own preferences class which becomes an object. The constructor fills in the properties with default values and keeps it in memory. 2) Nothing is written to xfconf. 3) The preferences object has getter and setter methods that triggers the xfconf backend. In case something changes, the changes are written. 4) Because of 1-3 everything is right. Thunar has no uninitialized values, because the preferences object already keeps track of default values. So the condition of Thunar is always right. 5) Where needed in the code, the code references a preferences object and accesses it's values with g_object_get. This triggers the object and gives the method the correct values. 6) Accessing the preferences object also triggers xfconf to see whether changed values have been written in the XML file. 7) Because of 6) we get the above error messages in Comment https://bugzilla.xfce.org/show_bug.cgi?id=11450#c74 that xfconf wasn't able to get "the misc-full-path-in-title" and "misc-file-size-binary" properties (possible more). 8) I will remove the setters and getters from the preferences class to avoid triggering xfconf. This - so my theory - will make Thunar operate with internal values. Copying, Moving etc. should't cause any crashes because xfconf is not being triggered at all. 9) If 8) is the case then I may continue search with dbus and xfconf.
After removing all traces for xfconf_get_property (basicly the entire if sequence) in the preferences getter, I was able to run thunar normally (with some small rarely occoured exceptions: later on [1]). As expected no triggering of xfconf happened. All values received from the object. This brought me to the conclusion, that xfconf or dbus might be the cause. So I bash scripted a small stress tester for xfconf to trigger exactly this property (which doesn't exist in my thunar channel). while [ 1 ] ; do xfconf-query -c thunar -p /misc-file-size-binary ; done No issues (even with thunar running aside). Then I reminded myself that I was running Thunar 1.6.4 (where this issue got introduced) with an older xfconf version. The same xfconf version that was used to run Thunar 1.6.3 with (which ran without issues). I looked closer to the getter and assumed that the xfconf_get_property might return something, regardles what it was and stores it. Which might cause the crash. I tried xfconf_has_property as a wrapper around the entire xfconf block but this ended up that the property is being triggered again through xfconf. Even asking for the existence of the property caused the same crash. [1] ... the later on thingy ... Even without xfconf stuff inside the prefs getter. Thunar has crashed on me the one or other time. I wonder if this might be the case with 1.6.3 as well (... and we haven't noticed because this particular property wasn't there). So what makes sense is to enforce a crash again and see whether this leads us to another backtrace... Maybe dbus again ?
Created attachment 6050 thunar-preferences.c testcase I made a small testcase for my theory about xfconf being triggered in the getter and this is the result. What remains is just a single g_print(...) and the "object" setter for default values. After that thunar got configured as follows: ./configure --disable-dbus --disable-gudev --prefix=/usr Runnin thunar through gdb and monitoring with dbus-monitor gave me rare crashes every now and then. Maybe from 50 copies around one crash. The backtraces look similar from them above but vary from time to time. Then I recompiled thunar again. This time I commented the g_print and never had any crashes again. Since neither xfconf nor dbus (besider the vfs layer) gets triggered. With dbus enabled in thunar, I rarely had some false unrefs there and here. They show up. Disappear. Sometimes I hit the exact problem as many logs has shown. Sometimes I hit some other areas inside glib. xfconf seem to be working ok, otherwise other problems might have shown up in other parts of xfce4. dbus ? I am not sure, this will raise the question why other parts of the distribution I use won't fail or trigger similar issues. Thread safe or race conditions comes into my mind as well.
Created attachment 6051 Fix for race condition Found it. thunar-transfer-job.c References preference object before the if return statements. This seem to be too much for getting things done "just in time". The method seem to be hit heavily. I moved the entire block below the if statements and never had a crash again. Please someone test.
Created attachment 6052 Improved patch This is a slightly optimized (and optional) version of the patch before. This time I looked closer to the preference reference calls (which usually calls the setter and/or getter methods, which otoh calls xfconf, which otoh penetrates dbus). I figured out that the preference referen calls is usually done at the beginning of functions. Later on it figures out that it might be required only one or two times in nested if/else statements. So chances are high, that the requirements to reference the object at the beginning is not necessary (causes a lot of traffic on the bus). I therefore moved the preference reference calls inside there where it (from my perspective) belongs. In one case two nested if statements inside. This should reduce noise on the dbus and hopefully reduces more possible race conditions.
André, can you have a look at binary size handling and check if it may have something to do with this issue (patch in comment #86 indicates it may be related). People who can reproduce this error, does toggling the "Show file size in binary format" option make any difference?
I really can't reproduce this bug. I tried lots of combinations and thunar versions(1.6.4, 1.6.5 and git), even removed the "misc-file-size-binary" prop from xfconf and nothing crashed. I've tried it on my laptop and desktop, both running Arch Linux fully updated. All evidences indicates that the problem was introduced by my commit and what Ali proposes makes sense to me. But it's awkward that the problem vanishes for people that set the property. IDK but maybe when the property is unset something is getting slower or errors might be silenced. Well, I'll try to reproduce this bug later, meanwhile if some one could apply Ali's patch, build thunar, remove the "misc-file-size-binary" property and give it a shot would be great.
At last, some testing I can help with. Here's my initial testing for the "Show file size in binary format" check box. Reneabled the dev PPA and upgraded to xfce 4.12. As expected, the very first file moving operating caused both thunar windows to crash. Then I toggled the check box in thunar's preferences, logged out and then back in again. No crash when moving the file. In fact, I haven't been able to make thunar crash at all now, *regardless* of the check box state. The best way I can describe the behaviour I am have experienced is something like to this... 1. Upgrade to new thunar. The binary setting is set to null by default, which produces the crash every single time a move operation is tried.. 2. After checking the box, the setting is changed to an acceptable value, 1. 3. Toggling the check box, the setting is changed to a different acceptable value, 0. Because the setting is never changed back to null, the crash seems to stop. Both 1 and 0 are acceptable values. I'll keep testing and if I get a crash I will post back. Does that make sense.
(In reply to André Miranda from comment #88) > Well, I'll try to reproduce this bug later, meanwhile if some one could > apply Ali's patch, build thunar, remove the "misc-file-size-binary" property > and give it a shot would be great. After applying one of these two offered patches, preferabely the "improved patch", you don't have to remove or set any property at all. The thunar.xml can be empty (start stop xfconfd and thunar --quit afterwards). Here an attempt of explaination: Race coditions depend on so many aspects. Speed of computer (Harddisk, CPU), Compile flags, Compiler used, Different types of libraries, Thread safe libs vs. non-thread safe libs. My investigations as follows: Is dbus 1.6.x the cause ? I don't think so, otherwise tons of other programs of my Fedora 20 installation (which I consider rock solid) must have triggered similar issues. Is xfconf 4.10/4.11/4.12 the cause ? I don't think so, otherwise ... (same as above). Is Thunar 1.6.4+ the cause ? My answer here is "most likely". On some machines the bug does not appear or appear rarely. This is due to different (newer) libraries which might be a tad more robust or offer better thread safety. Some machines might be faster, others not. Even compile options and architecture might take a role here. Setting the "binary size option" was my initial thought because I assumed that not having this flag set, might leave an unknown state. This is not the case as I learned later since the preferences object set default internal values. Now looking at it from different perspectives: Leave the code of thunar GIT (or 1.6.x) as is. Only remove all traces from the preferences getter to xfconf allows me to run thunar most of the time stable. Realy rare crashes! This means! The "may cause" code stays as is and thunar "works". No connections to xfconf. This leads to the believing that either xfconf or dbus may be buggy (let's assume it so) or that xfconf_property_get returns some undefined values which then gets copied into the preferences object. This is not the case either! But then I had that theory of dbus and xfconf being used plenty of time on my system and that it might be race condition. I then started to keep a closer look at the methods that introduced the object referencing of the preferences and thus asking to get the "binary size" attribute. I realized that referencing the preferences object and getting the "binary size" attribute is done at the beginning of the methods (nearly all the time). Even if it's not necessary to do this at all, because often the attribute is needed in a nested if/else statement. So when I enter the function and reference the preferences object at the beginning, then the code is being executed ALL the time (reference object, call to xfconf, call to dbus) regardless if we never hit the nested if/else statements. Placing the preferences object references close to where it's required makes sense. This will heavily reduce activity on the dbus and allows the if/else statements to leave without even the requirement to trigger it at all (performance imrpovement as well). Whenever "copying" is requested from the user then a new thread is being created and after copy is done, the thread is left again (gdb gives output of threads being entered and left). My investigations (if we leave thunar as is) is, that most of the time when we request "copy" or "move" that the thread is entered but not left and crashes (but the file, dir we triggered is copied as well). Having this in mind I assumed as follows: The file "thunar-transfer-job.c" which has these two if return statements at the close beginning. If something is empty (file list and or size) then instantly return. I don't know how often this function is called but I assume it might be a high frequent called one (depending on the amount of files and directories moved - it can also be the other way :) ). So we enter that method, trigger the object, return from the if/return clause and deal with the other files and dirs while "dbus and xfconf" are still dealing with the "initial" request of that particular "misc binary size" attribute. Leaves the final question: Why does it disappear when we explicit set the "misc binary size" attribute in the preferences (and leave the code untouched). Answer: Race condition, thread safety, <insert anything else>
Andrzej, I guess the last patch provided by Ali should be applied. Even though we aren't sure why the crashes stop when the option is set, moving the code that gets the property to where it's needed is much more optimal. Even if the problem is not completely solved, it won't do harm. When I wrote that code, I wasn't aware that it would be called so many times and that getting the property is somewhat costly. Now I wonder if this isn't a case for caching this property in order to avoid multiple (unnecessary) calls to dbus. Maybe Xfconf should handle this, if not each scenario has to be evaluated and the cache should be coded ad-hoc?(I guess the latter is kludge).
Also here: Changed the settings (even without logging out) and working like a charm now :)
The proper fix is to store the preference in the ThunarTransferJob struct and initialize this once in thunar_transfer_job_execute.
(In reply to André Miranda from comment #91) > Now I wonder if this isn't a case for caching this property in order to > avoid multiple (unnecessary) calls to dbus. Maybe Xfconf should handle this, > if not each scenario has to be evaluated and the cache should be coded > ad-hoc?(I guess the latter is kludge). Xfconf has an internal cache, but dbus communication only work in the main loop, and since the io jobs run in a separate thread pool it is not suitable for outside communication / ui updates. Just cache it in the structure and its ok.
Created attachment 6063 Another patch Crafted this patch following Nick's suggestion. Please verify if this is properly coded and whoever can reproduce this bug(which I can't) check if the problem is fixed(remember to reset/delete the property in Xfconf settings editor). Also available on: https://github.com/andreldm/thunar/commit/89ab185
will there be debs of the patched thunar available on the dev PPA for us to test? Or should we just wait for the more experienced people to test it?
(In reply to André Miranda from comment #95) > Please verify if this is properly coded and whoever can reproduce this > bug(which I can't) check if the problem is fixed(remember to reset/delete > the property in Xfconf settings editor). Applied the patch against current git version of thunar, compiled and installed it. killall xfconfd thunar --quit Removed the thunar.xml file in xfconf/*/thunar.xml After a few copies crash!
@Ali, so your patch probably doesn't fix this either. Can you confirm? Anyone else, ideas? If not, due the severity of this bug I'm considering to remove this feature for now, what do you guys think?
(In reply to André Miranda from comment #98) > @Ali, so your patch probably doesn't fix this either. I reverted back to thunar 1.6.6 with "improved patch" and have *no* issues. This is because I moved sections inside nested if blocks to avoid "nailing" dbus. Let's investigate here: thunar-gio-extensions.c -> both patches same thunar-size-label.c -> both patches same thunar-transfer-job.c -> both patches differ (of course) fkt "thunar_transfer_job_execute" Quick investigation triggering object before the for loop. This may cause the same amout of "nailing" traffic as the previous code in "thunar_transfer_job_veryify_destination". So basicly a new "high amount" of triggering has been introduced in a new function, while removed in the previous one. I will comment that particular part out of the code and re-compile thunar and report back as I type now. As I thought. I commented the object referencing block before the for loop and re-compiled. Problem gone.
Explaination (old patch): main() { while (1) { call_fkt_a(); // thunar_transfer_job_veryify_destination call_fkt_b(); // thunar_transfer_job_get_status } } call_fkt_a() { call_prefs_object_reference(); // calls xfconf which calls dbus if (foo file list exist) { return; } if (nested block) { fkt_gimme_misc_binary_size_info(); } } call_fkt_b() { ; // left untouched } My patch only reduced noise on the bus: main() { while (1) { call_fkt_a(); // thunar_transfer_job_veryify_destination call_fkt_b(); // thunar_transfer_job_get_status } } call_fkt_a() { if (foo file list exist) { return; } if (nested block) { call_prefs_object_reference(); // calls xfconf which calls dbus fkt_gimme_misc_binary_size_info(); } } call_fkt_b() { ; // left untouched } The new patch does: main() { while (1) { call_fkt_a(); // thunar_transfer_job_veryify_destination call_fkt_b(); // thunar_transfer_job_get_status } } call_fkt_a() { if (foo file list exist) { return; } if (nested block) { get_from_cache(); fkt_gimme_misc_binary_size_info(); } } call_fkt_b() { call_prefs_object_reference(); // calls xfconf which calls dbus store_in_cache(); } But looking in the main section and in the while statement, both functions are called sequentially (and probably (this is just my guess)) with the same fequency. So basicly from guessing by the functions name, the function "thunar_transfer_job_execute" seem to be from same high frequency than the "check_destination" one, where this preference object referencing was done before (if not higher) -> nails dbus.
"thunar_transfer_job_get_status" in the comment part of the pseudo code should mean "thunar_transfer_job_execute" :)
Created attachment 6066 test case for scenario Please find attached a test case for my scenario: Your old patch: Preferences Object referencing in "thunar_transfer_job_veryify_destination" Your new patch: Preferences Object referencing in "thunar_transfer_job_execute" Let's replace your old referencing and new referencing with a normal g_print. What we see is this. After compile (I ran it inside the git tree): I copied (moved) 8 files at once from A to B thunar/.libs/thunar &> fkt1.txt grep "destination" fkt1.txt | wc -l 1 grep "execute" fkt1.txt | wc -l 1 Then I ran thunar once again. This time I copied (moved) 8 files one by one from A to B thunar/.libs/thunar &> fkt2.txt grep "destination" fkt2.txt | wc -l 8 grep "execute" fkt2.txt | wc -l 8 The theory has been confirmed that regardless if you reference the Preferences Object in either fkt_destination OR fkt_execute, they both get triggered the same amout of time. So basicly the new patch only moved object referencing from one function to another, which results in the same experience.
My excuses for the high traffic I may cause here. Something that I noticed and that raised some questions in my mind was this: why does preference object reference only cause problems in the thunar-transfer-job.c file ? I mean, there are plenty of preference object references spread over the entire thunar code. Why is the crash only happen in this particular *.c file ? This should also happen, if I query other settings that way. The functions "thunar_transfer_job_veryify_destination" and "thunar_transfer_job_execute" are connected together. Means "thunar_transfer_job_execute" is the top function that executes the "thunar_transfer_job_veryify_destination" function. But thunar_transfer_job_execute seem to be a exojob_class->execute reference as found in the thunar_transfer_job_class_init function of the same file. This is the only "unique" difference (handed over to exo) to most other areas of thunar where the preferences object is referenced. So basicly and theoreticaly it doesn't matter whether we g_object_get "misc-file-size-binary" or anything else. It will result in a crash. thunar_transfer_job_veryify_destination (using GIT version as is) preferences = thunar_preferences_get (); g_object_get (preferences, "misc-file-size-binary", &file_size_binary, NULL); g_object_unref (preferences); ... we know will crash ... Replaced "misc-file-size-binary" with this: g_object_get (preferences, "misc-middle-click-in-tab", &open_in_tab, NULL); ... crash ... Now only this: preferences = thunar_preferences_get (); g_object_unref (preferences); ... no crash ... Let's make some adress tests. Is the object in preferences still the same object as in thunar_transfer_job_veryify_destination ? thunar_preferences_get_property: preferences object address: 8c1c850 thunar_transfer_job_veryify_destination: preferences object address: 8c1c850 Yes it is. At least let's believe this is. Now that I assume that this object is being handed over to exo (?). Does exo still know that this address is an g_object ? Or does g_object_get know that this still is an object ? Let's put some casts around it: preferences = thunar_preferences_get (); g_object_get (G_OBJECT (preferences), "misc-file-size-binary", &file_size_binary, NULL); g_object_unref (G_OBJECT (preferences)); ... sadly this leads to crashes after a while again ... I was typing this text during experiments with thunar over the past 1-2 hours now. I thought that it might be that the object reference might become broken and g_object_get might get irritated that this may not be understood as object. But this has proven me wrong ... Still the only unique difference between other parts of thunar and here is, exo.
Created attachment 6069 Rework-usage-of-binary-file-size-properties-bug-11450.patch With the patch attached I have tried to rework the preference handling of misc-file-size-binary a little and for all components. The preference is read in the initialization of the component, and changes are propagated by signals where possible. This way, there should not be any performance problems, and as a bonus, a change of this preference should have an immediate effect (properties dialog, status bar, job window), the exception being the column view where I still have to find out what is missing. Many components have already made use of a preference object already, so there was not much to add. I tested it and it worked without crashes, but on my system I cannot reproduce the bug, so I cannot tell for sure. Please try and report back if it also fixes the issue or if you have any problems.
*** Bug 11448 has been marked as a duplicate of this bug. ***
Sorry, was off for a few days. Just tested the patch from Harald with todays checkout of thunar (GIT) and confirm that this works without any crashes. The patch seem a bit more complex, but took the requirements for object referencing out of most areas which is good. I even started with a new thunar instance to experiment with it (means removing thunar.xml and restarted xfconfd). Selecting the "misc-binary-size" option also shows different values as expected. From my point this should be applied to GIT.
*** Bug 11594 has been marked as a duplicate of this bug. ***
Thanks for testing, pushed to master: http://git.xfce.org/xfce/thunar/commit/?id=9931530b40ef94044c9ea4dca535e26ceced7838
Is there likely to be a new release with this fix? Or should distros look to backport this?
Does anyone know when a new version of Thunar will be released incorporating the fix? There are a quite a few of us who aren't able to enjoy xfce 4.12 because the thunar bug was a show stopper.
(In reply to slumbergod from comment #110) > Does anyone know when a new version of Thunar will be released incorporating > the fix? > > There are a quite a few of us who aren't able to enjoy xfce 4.12 because the > thunar bug was a show stopper. To work around the issue, it should suffice to go to Preferences and check/uncheck "Show file size in binary format".
I re-enabled the PPA, upgraded, checked the box in Thunar's preferences. I still managed to get a crash and lose some files that were being moved. One crash out of 24 hours usage is certainly better but still one crash too many. Has anyone else had a crash or is it fixed 100% for everyone now?
That is likely a different issue. Would it be possible for you to capture a stacktrace? (if so, remember to install relevant -dbg packages)
(In reply to slumbergod from comment #112) > I re-enabled the PPA, upgraded, checked the box in Thunar's preferences. > > I still managed to get a crash and lose some files that were being moved. Enabling the "misc-binary-size" option in thunar 1.6.6 was not the solution. It only reduced the crash to show up to a minimum. E.g. before you had 1 crash by 1 file operation. After enabling the setting (and/or disabling it again) the crash had reduced to e.g. 1 out of 10/20 file operations. It was more or less a quick and dirty error trial solution that I found by experiments. > Has anyone else had a crash or is it fixed 100% for everyone now? The propwer fix is the reworked one by Harald. Please ask your PPA provider to re-release thunar 1.6.6 with that patch applied.
I would humbly suggest taht this fix warrants an "emergency" release, even a minor one containing only this patch: 1.66.1
Ahhh, thanks for clarifying it Ali. I'll just ppa-purge the repo and patiently wait.
I applied this patch against 1.6.6, installed, stopped all Thunar instances, then opened Thunar and started moving files one-by-one into a different folder. New segfault. (thunar:8509): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed *** Error in `thunar': free(): invalid next size (fast): 0x00007f769801af20 *** Aborted (core dumped)
And related trace: https://www.dropbox.com/s/iggkodgfnn6q58x/_usr_bin_thunar.1000.crash?dl=0
This bug has been reported fixed by the commit in comment #108. Other crashes likely have another cause, most probably bug #11008. Please do not report them to the closed bug report here, with the exception being that the original bug really has not been fixed, which likely means dbus errors in traces, not anything else.