thunar crashes on drag drop file/folder

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 <email address hidden>
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...

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-...

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/build...

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

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 creat...

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.