thunar crashes on drag drop file/folder
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Thunar File Manager |
Fix Released
|
Critical
|
|||
thunar (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Thunar 1.6.6 (Xfce 4.12)
As the title says, every time I try to drag something to somewhere, it crashes. The only exception I have seen so far is dragging into the side pane.
System:
Xubuntu 14.04.1 LTS
In Xfce Bugzilla #11450, faustus69 (aclbros14) wrote : | #3 |
Hi,
Same problem here. This is the dmesg output:
-------
[14614.191656] Thunar[1551]: segfault at 4 ip 00007f28d6ce7d80 sp 00007fff948effa8 error 6 in libdbus-
-------
Same error using context menu "Send to:" to an USB pendrive.
Thanks!
In Xfce Bugzilla #11450, Matt Thirtytwo (LinuxMatt) (matt-59491) wrote : | #4 |
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,
In Xfce Bugzilla #11450, faustus69 (aclbros14) wrote : | #5 |
Hi, thunar installed from xubuntu-dev PPA
Xubuntu 14.04.1 x86_64
Kernel: 3.18.0-
$ apt-cache policy thunar
thunar:
Instalados: 1.6.4-0ubuntu1~
Candidato: 1.6.4-0ubuntu1~
Tabla de versión:
*** 1.6.4-0ubuntu1~
500 http://
100 /var/lib/
1.6.3-1ubuntu5 0
500 http://
$ 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://
500 http://
100 /var/lib/
1.
500 http://
In Xfce Bugzilla #11450, Kevin Nadaud (kevin-nadaud) wrote : | #6 |
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
In Xfce Bugzilla #11450, nirik (kevin-scrye) wrote : | #7 |
A number of Fedora users are seeing this issue with 1.6.4 as well.
See downstream bug:
https:/
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...
In Xfce Bugzilla #11450, Kevin Nadaud (kevin-nadaud) wrote : | #8 |
dbus version is 1.6.18 in trusty (14.04).
In Xfce Bugzilla #11450, Zirneklitis (eko-lanet) wrote : | #9 |
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-
Downgrade to the previous version (1.6.3-2) solves the issue.
In Xfce Bugzilla #11450, Matt Thirtytwo (LinuxMatt) (matt-59491) wrote : | #10 |
Bug can be reproduced with 'git master', gdb backtrace on LinuxMint 17.1 / Ubuntu 14.04 :
#0 _dbus_watch_
#1 0x00007ffff54409cd in free_watches (transport=
#2 0x00007ffff5440a39 in socket_disconnect (transport=
#3 0x00007ffff543fea7 in _dbus_transport
#4 0x00007ffff5440675 in _dbus_transport
#5 0x00007ffff5429539 in _dbus_connectio
#6 0x00007ffff5429f86 in dbus_connection
#7 0x00007ffff566dcc3 in message_
#8 0x00007ffff4b9a68d in g_main_
#9 0x00007ffff4b9af03 in g_main_
#10 0x00007ffff4b9b30a in g_main_loop_run (loop=0xaa3b00) at /build/
#11 0x00007ffff6a24447 in IA__gtk_main () at /build/
#12 0x000000000042065b in main (argc=1, argv=0x7fffffff
In Xfce Bugzilla #11450, TuroLate (turolate) wrote : | #11 |
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_
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5445d80 in ?? () from /lib/x86_
In Xfce Bugzilla #11450, TuroLate (turolate) wrote : | #12 |
Sorry forgot to add, I'm running Xubuntu 14.04.1 with the xubuntu-dev PPA
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #13 |
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.
In Xfce Bugzilla #11450, Steve Dodier-Lazaro (sidi) wrote : | #14 |
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).
In Xfce Bugzilla #11450, Steve Dodier-Lazaro (sidi) wrote : | #15 |
For the backtrace, try to get down the trace to the _dbus_transport
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:/
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #16 |
Here we go:
Thunar v1.6.4 from https:/
libdbus-1-3 v1.6.18
Xubuntu 64bit
geek@liv-
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_
This is normally a bug in some application using the D-Bus library.
Segmentation fault (core dumped)
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #17 |
Some more info. Apport reports:
thunar crashed with SIGSEGV in dbus_message_
Here's the report it has produced:
http://
You can open it with Apport, it seems.
In Xfce Bugzilla #11450, Simon Steinbeiß (ochosi) wrote : | #18 |
Would be great if one of you who can reproduce can bisect and identify the commit that introduced the regression in 1.6.4.
In Xfce Bugzilla #11450, Simon Steinbeiß (ochosi) wrote : | #19 |
The only commit directly related to copying I could see when browsing git is this one: http://
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #20 |
Simon,
I have only approximate familiarity with git bisect. How can I bisect while omitting only this specific commit:
http://
?
Thanks!
In Xfce Bugzilla #11450, Simon Steinbeiß (ochosi) wrote : | #21 |
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://
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #22 |
GIT bisect points me to this:
5bce93830d10052
commit 5bce93830d10052
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 0dfac981efff86b
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #23 |
Is the GIT bisect useful, or would it help devels if I provided a gdb trace?
In Xfce Bugzilla #11450, Steve Dodier-Lazaro (sidi) wrote : | #24 |
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!
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #25 |
For valgrind, do I need to recompile Thunar with debugging symbols enabled?
In Xfce Bugzilla #11450, Steve Dodier-Lazaro (sidi) wrote : | #26 |
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.
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #27 |
OK, I installed all debugging packages that I could spot. Please advise if there are others that I need to install.
http://
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...
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #28 |
I installed some additional debugging symbols. Here's what I think is a more complete version of the valgrind debug:
http://
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 ".
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #29 |
And for good measure a gdb trace:
geek@liv-
GNU gdb (Ubuntu 7.7-0ubuntu3) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://
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://
Find the GDB manual and other documentation resources online at:
<http://
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from thunar...Reading symbols from /usr/lib/
done.
(gdb) run
Starting program: /usr/bin/thunar
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_
[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_
(thunar:1010): GLib-CRITICAL **: Source ID 296 was not found when attempting to remove it
Program received signal SIGSEGV, Segmentation fault.
_dbus_watch_
171 ../../dbus/
(gdb) bt
#0 _dbus_watch_
#1 0x00007ffff54449cd in free_watches (transport=
#2 0x00007ffff5444a39 in socket_disconnect (transport=
#3 0x00007ffff5443ea7 in _dbus_transport
#4 0x00007ffff5444675 in _dbus_transport
#5 0x00007ffff542d539 in _dbus_connectio
#6 0x00007ffff542df86 in dbus_connection
#7 0x00007ffff5671cc3 in message_
#8 0x00007ffff4b9e68d in g_main_
#9 0x00007ffff4b9ef03 in g_main_
at /build/
#10 0x00007ffff4b9f30a in g_main_loop_run (loop=0x5555560
#11 0x00007ffff6a28417 in gtk_main () from /usr/lib/
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #30 |
And another one. For some reason the gdb traces are sometimes different:
geek@liv-
GNU gdb (Ubuntu 7.7-0ubuntu3) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://
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://
Find the GDB manual and other documentation resources online at:
<http://
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from thunar...Reading symbols from /usr/lib/
done.
(gdb) run
Starting program: /usr/bin/thunar
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_
[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_
(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_
171 ../../dbus/
(gdb) bt
#0 _dbus_watch_
#1 0x00007ffff54449cd in free_watches (transport=
#2 0x00007ffff5444a39 in socket_disconnect (transport=
#3 0x00007ffff5443ea7 in _dbus_transport
#4 0x00007ffff5444675 in _dbus_transport
#5 0x00007ffff5444fae in do_reading (transport=
#6 0x00007ffff5445666 in socket_do_iteration (transport=
#7 0x00007ffff54443ff in _dbus_transport
at ../../dbus/
#8 0x00007ffff542e9fc in _dbus_connectio
timeout_
#9 0x00007ffff542f3a9 in _dbus_connectio
In Xfce Bugzilla #11450, Steve Dodier-Lazaro (sidi) wrote : | #31 |
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 :-)
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #32 |
Crash still here with the vcs plugin uninstalled:
Reading symbols from thunar...Reading symbols from /usr/lib/
done.
(gdb) run
Starting program: /usr/bin/thunar
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_
[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_
(thunar:20969): GLib-CRITICAL **: Source ID 315 was not found when attempting to remove it
Program received signal SIGSEGV, Segmentation fault.
__memmove_
1544 ../sysdeps/
(gdb) bt
#0 __memmove_
#1 0x00007ffff544941d in memmove (__len=<optimized out>, __src=<optimized out>,
__dest=
#2 delete (start=
at ../../dbus/
#3 0x00007ffff5449d00 in delete (real=real@
real=
at ../../dbus/
#4 _dbus_string_delete (str=str@
at ../../dbus/
#5 0x00007ffff543c68d in load_message (body_len=82, header_len=136,
fields_
loader=
#6 _dbus_message_
at ../../dbus/
#7 0x00007ffff5444520 in _dbus_transport
transport=
#8 0x00007ffff5444653 in _dbus_transport
at ../../dbus/
---Type <return> to continue, or q <return> to quit---
#9 0x00007ffff542d539 in _dbus_connectio
connection=
#10 0x00007ffff542df86 in dbus_connection
at ../../dbus/
#11 0x00007ffff5671cc3 in message_
timeout=
#12 0x00007ffff4b9e68d in g_main_
priority=
#13 0x00007ffff4b9ef03 in g_main_
dispatch=
at /build/
#14 0x00007ffff4b9f30a in g_main_loop_run (loop=0x5555560
at /build/build...
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #33 |
And I no longer notice any invalid issues with valgrind:
http://
I think the VCS plugin is only incidental to the crashes, as now it's not installed...
In Xfce Bugzilla #11450, Zirneklitis (eko-lanet) wrote : | #34 |
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-
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #35 |
For info, I keep getting copy-related crashes in 1.6.5.
In Xfce Bugzilla #11450, Matt Thirtytwo (LinuxMatt) (matt-59491) wrote : | #36 |
@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:/
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #37 |
As mentioned in https:/
Would it help if I compiled 5bce93830d10052
In Xfce Bugzilla #11450, Matt Thirtytwo (LinuxMatt) (matt-59491) wrote : | #38 |
@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 ?
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #39 |
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.
In Xfce Bugzilla #11450, Hjudt-l (hjudt-l) wrote : | #40 |
I too do not experience any crashes here.
Aside from dbus, could the glib version used have any influence here?
sys-apps/
dev-libs/
dev-libs/
x11-libs/
43 comments hidden Loading more comments | view all 123 comments |
In Xfce Bugzilla #11450, Aliakc (aliakc) wrote : | #84 |
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:/
get "the misc-full-
(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.
In Xfce Bugzilla #11450, Aliakc (aliakc) wrote : | #85 |
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-
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 ?
In Xfce Bugzilla #11450, Aliakc (aliakc) wrote : | #86 |
Created attachment 6050
thunar-
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.
In Xfce Bugzilla #11450, Aliakc (aliakc) wrote : | #87 |
Created attachment 6051
Fix for race condition
Found it.
thunar-
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.
In Xfce Bugzilla #11450, Aliakc (aliakc) wrote : | #88 |
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.
In Xfce Bugzilla #11450, Andrzej-k (andrzej-k) wrote : | #89 |
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?
In Xfce Bugzilla #11450, André Miranda (andreldm) wrote : | #90 |
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-
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-
In Xfce Bugzilla #11450, Slumbergod-n (slumbergod-n) wrote : | #91 |
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 Xfce Bugzilla #11450, Aliakc (aliakc) wrote : | #92 |
(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-
> 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...
In Xfce Bugzilla #11450, André Miranda (andreldm) wrote : | #93 |
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).
In Xfce Bugzilla #11450, ogghi (david-) wrote : | #94 |
Also here:
Changed the settings (even without logging out) and working like a charm now :)
In Xfce Bugzilla #11450, 8-nick (8-nick) wrote : | #95 |
The proper fix is to store the preference in the ThunarTransferJob struct and initialize this once in thunar_
In Xfce Bugzilla #11450, 8-nick (8-nick) wrote : | #96 |
(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.
In Xfce Bugzilla #11450, André Miranda (andreldm) wrote : | #97 |
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:/
In Xfce Bugzilla #11450, Slumbergod-n (slumbergod-n) wrote : | #98 |
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 Xfce Bugzilla #11450, Aliakc (aliakc) wrote : | #99 |
(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!
In Xfce Bugzilla #11450, André Miranda (andreldm) wrote : | #100 |
@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 Xfce Bugzilla #11450, Aliakc (aliakc) wrote : | #101 |
(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-
thunar-size-label.c -> both patches same
thunar-
fkt "thunar_
Quick investigation triggering object before the for loop. This may cause the same amout of "nailing" traffic as the previous code in "thunar_
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.
In Xfce Bugzilla #11450, Aliakc (aliakc) wrote : | #102 |
Explaination (old patch):
main() {
while (1) {
call_fkt_a(); // thunar_
call_fkt_b(); // thunar_
}
}
call_fkt_a() {
call_
if (foo file list exist) {
return;
}
if (nested block) {
fkt_
}
}
call_fkt_b() {
; // left untouched
}
My patch only reduced noise on the bus:
main() {
while (1) {
call_fkt_a(); // thunar_
call_fkt_b(); // thunar_
}
}
call_fkt_a() {
if (foo file list exist) {
return;
}
if (nested block) {
call_
fkt_
}
}
call_fkt_b() {
; // left untouched
}
The new patch does:
main() {
while (1) {
call_fkt_a(); // thunar_
call_fkt_b(); // thunar_
}
}
call_fkt_a() {
if (foo file list exist) {
return;
}
if (nested block) {
get_
fkt_
}
}
call_fkt_b() {
call_
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_
In Xfce Bugzilla #11450, Aliakc (aliakc) wrote : | #103 |
"thunar_
In Xfce Bugzilla #11450, Aliakc (aliakc) wrote : | #104 |
Created attachment 6066
test case for scenario
Please find attached a test case for my scenario:
Your old patch:
Preferences Object referencing in "thunar_
Your new patch:
Preferences Object referencing in "thunar_
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.
In Xfce Bugzilla #11450, Aliakc (aliakc) wrote : | #105 |
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-
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_
Means "thunar_
But thunar_
So basicly and theoreticaly it doesn't matter whether we g_object_get "misc-file-
thunar_
preferences = thunar_
g_object_get (preferences, "misc-file-
g_object_unref (preferences);
... we know will crash ...
Replaced "misc-file-
g_object_get (preferences, "misc-middle-
... crash ...
Now only this:
preferences = thunar_
g_object_unref (preferences);
... no crash ...
Let's make some adress tests. Is the object in preferences still the same object as in thunar_
thunar_
thunar_
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_
g_object_get (G_OBJECT (preferences), "misc-file-
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.
In Xfce Bugzilla #11450, Hjudt-l (hjudt-l) wrote : | #106 |
Created attachment 6069
Rework-
With the patch attached I have tried to rework the preference handling of misc-file-
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.
In Xfce Bugzilla #11450, Hjudt-l (hjudt-l) wrote : | #107 |
*** Bug 11448 has been marked as a duplicate of this bug. ***
In Xfce Bugzilla #11450, Aliakc (aliakc) wrote : | #108 |
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.
In Xfce Bugzilla #11450, Hjudt-l (hjudt-l) wrote : | #109 |
*** Bug 11594 has been marked as a duplicate of this bug. ***
In Xfce Bugzilla #11450, Hjudt-l (hjudt-l) wrote : | #110 |
Thanks for testing, pushed to master: http://
In Xfce Bugzilla #11450, nirik (kevin-scrye) wrote : | #111 |
Is there likely to be a new release with this fix? Or should distros look to backport this?
In Xfce Bugzilla #11450, Slumbergod-n (slumbergod-n) wrote : | #112 |
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 Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #113 |
(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".
In Xfce Bugzilla #11450, Slumbergod-n (slumbergod-n) wrote : | #114 |
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?
In Xfce Bugzilla #11450, Andrzej (ndrwrdck) wrote : | #115 |
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 Xfce Bugzilla #11450, Aliakc (aliakc) wrote : | #116 |
(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.
In Xfce Bugzilla #11450, Liviu Andronic (landronimirc) wrote : | #117 |
I would humbly suggest taht this fix warrants an "emergency" release, even a minor one containing only this patch: 1.66.1
In Xfce Bugzilla #11450, Slumbergod-n (slumbergod-n) wrote : | #118 |
Ahhh, thanks for clarifying it Ali. I'll just ppa-purge the repo and patiently wait.
In Xfce Bugzilla #11450, Bluesabre-1 (bluesabre-1) wrote : | #119 |
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-
*** Error in `thunar': free(): invalid next size (fast): 0x00007f769801af20 ***
Aborted (core dumped)
In Xfce Bugzilla #11450, Bluesabre-1 (bluesabre-1) wrote : | #120 |
And related trace: https:/
In Xfce Bugzilla #11450, Hjudt-l (hjudt-l) wrote : | #121 |
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.
119 comments hidden Loading more comments | view all 123 comments |
Md. Jahidul Hamid (neurobin) wrote : | #1 |
It happens on simple copy too, when I am on the same thunar window and trying to copy file/folder inside another
Changed in thunar (Ubuntu): | |
status: | New → Confirmed |
Changed in thunar: | |
importance: | Unknown → Critical |
status: | Unknown → Fix Released |
120 comments hidden Loading more comments | view all 123 comments |
Launchpad Janitor (janitor) wrote : | #122 |
This bug was fixed in the package thunar - 1.6.6-1ubuntu2
---------------
thunar (1.6.6-1ubuntu2) vivid-proposed; urgency=medium
* Add patch to prevent crash on move (LP: #1439288)
- debian/
-- Sean Davis <email address hidden> Fri, 03 Apr 2015 21:56:13 -0400
Changed in thunar (Ubuntu): | |
status: | Confirmed → Fix Released |
Md. Jahidul Hamid (neurobin) wrote : | #123 |
I have installed thunar 1.6.6 in my xububtu 14.04.1 LTS and it seems to be working. Here's how I installed it:
First download the .deb packages from here (total 5 of them):
https:/
put them in a new directory, and cd to that directory
Now run:
sudo dpkg -i *.deb //it will show error but still you have to do it
sudo apt-get install -f
sudo dpkg -i *.deb
Select a file.
Ctrl+C to copy
Ctrl+V to create the copy > THUNAR CRASH