[SRU] thunar crashes on file renaming

Bug #1512120 reported by Daniel Kessel on 2015-11-01
638
This bug affects 125 people
Affects Status Importance Assigned to Milestone
thunar
Fix Released
High
thunar (Ubuntu)
Status tracked in Zesty
Xenial
Undecided
Sean Davis
Yakkety
Undecided
Sean Davis
Zesty
High
Marcos

Bug Description

[Impact]
 * Thunar crashes frequently when renaming files.
 * All open Thunar windows are closed, disrupting a user's workflow.
 * There have been several patches addressing this issue since the bug
   was originally reported, and numerous users are now reporting that
   the issue is resolved.

[Test Case]
 * Backup the file you will be testing to a different location.
 * Rename or move a file several times. When present, the bug may cause
   Thunar to crash on the first rename or after several.

[Regression Potential]
 * The patches have not been tested in all possible configurations,
   and could result in unexpected behavior (possibly additional crashing).
 * However, with the frequency that this bug crashes Thunar with the
   existing package, any reduction in the number of crashes are welcome.
 * Since Thunar is a file manager, there is a risk of data loss when
   testing this bug and potentially instigating a crash.

[Original Report]
When renaming files in a folder while re-sorting similarly named files, thunar crashes fairly often. Apport does not detect the crashes.

Running thunar in valgrind produces these log entries in the moment of the crash:

==28859== Thread 1:
==28859== Invalid read of size 1
==28859== at 0x04c2ffd3: strcmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28859== by 0x0014590c: thunar_file_compare_by_name (within /usr/bin/thunar)
==28859== by 0x00153e3d: thunar_list_model_cmp_func (within /usr/bin/thunar)
==28859== by 0x07e4da23: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.1)
==28859== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==28859==
==28859== Process terminating with default action of signal 11 (SIGSEGV)
==28859== Access not within mapped region at address 0x0
==28859== at 0x04c2ffd3: strcmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28859== by 0x0014590c: thunar_file_compare_by_name (within /usr/bin/thunar)
==28859== by 0x00153e3d: thunar_list_model_cmp_func (within /usr/bin/thunar)
==28859== by 0x07e4da23: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.1)
==28859== If you believe this happened as a result of a stack
==28859== overflow in your program's main thread (unlikely but
==28859== possible), you can try to increase the size of the
==28859== main thread stack using the --main-stacksize= flag.
==28859== The main thread stack size used in this run was 8388608.
==28859==
==28859== HEAP SUMMARY:
==28859== in use at exit: 11,169,056 bytes in 101,668 blocks
==28859== total heap usage: 8,917,549 allocs, 8,815,881 frees, 736,520,410 bytes allocated
==28859==
==28859== For counts of detected and suppressed errors, rerun with: -v
==28859== Use --track-origins=yes to see where uninitialised values come from
==28859== ERROR SUMMARY: 1046 errors from 45 contexts (suppressed: 0 from 0)
==28859==

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: thunar 1.6.10-1
ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3
Uname: Linux 4.2.0-16-generic x86_64
ApportVersion: 2.19.1-0ubuntu4
Architecture: amd64
CurrentDesktop: XFCE
Date: Sun Nov 1 18:57:09 2015
InstallationDate: Installed on 2015-02-05 (268 days ago)
InstallationMedia: Xubuntu 15.04 "Vivid Vervet" - Alpha amd64 (20150205)
SourcePackage: thunar
UpgradeStatus: Upgraded to wily on 2015-05-28 (156 days ago)

Created attachment 6482
Backtrace

Thunar randomly crashes (SIGSEGV) when renaming files.

Reproducible: Random
Steps to Reproduce:
1. Start up Thunar.
2. Go to some directory with single file.
3. Rename that file
4. Change the filename and press enter.
5. Not crashed? Try step 3 again.

Crashes even for single file in whole folder. It is strange that if you run it with gdb then the crash is not so often.

gdb backtrace attached - it is strange that the thunar_file_compare_by_name() function is called even for only one file in working directory - both file_a->collate_key_nocase and file_b->collate_key_nocase are NULL. I noticed that sometimes this function is not called, but when it is (it is random), then it crashes.

Created attachment 6483
check-thunar-file-instance-when-comparing-filenames.patch

> gdb backtrace attached - it is strange that the
> thunar_file_compare_by_name() function is called even for only one file in
> working directory - both file_a->collate_key_nocase and
> file_b->collate_key_nocase are NULL. I noticed that sometimes this function
> is not called, but when it is (it is random), then it crashes.

This is probably related to threading issues and timing-specific. Something needs to be protected to avoid being accessed when it shouldn't be. Likely the old file is in the process of being destroyed while being compared with the new file or something like that.

Does the attached workaround prevent the crashes? It is not a proper fix we can apply, but until we have a good solution it could help.

(In reply to Harald Judt from comment #1)
> Created attachment 6483 [details]
> check-thunar-file-instance-when-comparing-filenames.patch
>
> > gdb backtrace attached - it is strange that the
> > thunar_file_compare_by_name() function is called even for only one file in
> > working directory - both file_a->collate_key_nocase and
> > file_b->collate_key_nocase are NULL. I noticed that sometimes this function
> > is not called, but when it is (it is random), then it crashes.
>
> This is probably related to threading issues and timing-specific. Something
> needs to be protected to avoid being accessed when it shouldn't be. Likely
> the old file is in the process of being destroyed while being compared with
> the new file or something like that.
>

It can be the reason why running Thunar with gdb has about 10 times less crashes. I also noticed that sometimes, when I rename file, there appears second file with the same name like the first one (checked it with "ls -l" - there is only one real file).

> Does the attached workaround prevent the crashes? It is not a proper fix we
> can apply, but until we have a good solution it could help.

Well, this workaround does not help. The problem is that THUNAR_IS_FILE returns true (for file_a and file_b), but pointers to collate_key are NULL. There has to be another test if file_a->collate_key or file_a->collate_key are NULL.

I wonder what makes my system different it crash so often.

By the way, this bug could be related to https://bugzilla.xfce.org/show_bug.cgi?id=12253 (I did not noticed it while I was opening this bug)

I would like to confirm this bug which I noticed after the upgrade from Xubuntu 15.04 to Xubuntu 15.10. The workaround is to click the rename button with the mouse instead of using the Enter key after setting the new filename.

(In reply to Rafael Gattringer from comment #4)
> I would like to confirm this bug which I noticed after the upgrade from
> Xubuntu 15.04 to Xubuntu 15.10. The workaround is to click the rename button
> with the mouse instead of using the Enter key after setting the new filename.

Not for me it isn't.

I am finding that clicking the rename button is failing about 50-75% of the time and crashing the Thunar window the same as hitting enter.

This is a real problem when trying to rename a lot of files... :-/

This may not be a Thunar problem. This may be due to a recent upgrade to glib2. See here, particularly comment #12:

https://bbs.archlinux.org/viewtopic.php?id=203663

And here:

https://bugs.archlinux.org/task/46666

I am running Manjaro with the XFCE GUI. My laptop and desktop both have the same version of Manjaro, same 4.1 kernel, and the same version of Thunar, yet the laptop isn't having the problem.

I just checked and my laptop version of glib2 is glib2-2.44.1-1- the one the commenter said is stable. Yes, he's talking about drag and drop- but the fact that my laptop with the earlier version of glib2 doesn't exhibit the problem can't be a coincidence.

I don't have my desktop computer on right now- the one that IS having the problem- but I'll bet that when I turn it on tomorrow and check- my version of glib2 will be the newer problematic one, glib2-2.46.0-2.

Created attachment 6515
dont-unref-null.patch

While investigating the bug I came across a glib-critical. Attached is a simple patch which fixes this critical, but probably not the bug itself. Nevertheless it might be somehow related so I post it here.

Daniel Kessel (dkessel) wrote :
tags: added: xubuntu
summary: - crashes on file renaming
+ thunar crashes on file renaming

Sure enough, I checked and my desktop had the problematic version of glib2- glib2-2.46.0-2.

I installed the latest round of Manjaro updates, bringing glib2 up to glib2-2.46.1-1.

It's still crashing.

The new version isn't stable either. The only stable version has been glib2-2.44.1-1.

Somebody on the Manjaro forum posted this workaround:

https://tunwinnaing.wordpress.com/2015/04/01/workaround-thunar-file-manager-crash-on-moving-files/

I didn't have the option enabled in Thunar, so I checked the box to enable it. So far it is working.

Whether or not this will still work after a reboot I don't know, but I was just able to do a dozen folder & file renames without Thunar crashing.

(In reply to Harald Judt from comment #1)
> > gdb backtrace attached - it is strange that the
> > thunar_file_compare_by_name() function is called even for only one file in
> > working directory - both file_a->collate_key_nocase and
> > file_b->collate_key_nocase are NULL. I noticed that sometimes this function
> > is not called, but when it is (it is random), then it crashes.
>
> This is probably related to threading issues and timing-specific. Something
> needs to be protected to avoid being accessed when it shouldn't be. Likely
> the old file is in the process of being destroyed while being compared with
> the new file or something like that.

I have a similar or identical backtrace to the one posted in the original bug report. I also cannot rename files without thunar going away on me.

I don't know if it helps at all, but I used gdb to print some extra info from the last stack frame reached in thunar. I hope the Xfce team can solve this soon, because I have to sort out some old backed-up directories and I'm used to using thunar to do this sort of work!

(gdb) frame 1
#1 0x000055555559188d in thunar_file_compare_by_name (file_a=0x555555d3e390, file_b=0x555555d2dd00, case_sensitive=<optimized out>) at thunar-file.c:4027
4027 result = strcmp (file_a->collate_key, file_b->collate_key);

(gdb) info frame
Stack level 1, frame at 0x7fffffffd380:
 rip = 0x55555559188d in thunar_file_compare_by_name (thunar-file.c:4027); saved rip = 0x55555559fd9e
 called by frame at 0x7fffffffd3b0, caller of frame at 0x7fffffffd360
 source language c.
 Arglist at 0x7fffffffd360, args: file_a=0x555555d3e390, file_b=0x555555d2dd00, case_sensitive=<optimized out>
 Locals at 0x7fffffffd360, Previous frame's sp is 0x7fffffffd380
 Saved registers:
  rbx at 0x7fffffffd368, rbp at 0x7fffffffd370, rip at 0x7fffffffd378

(gdb) print *file_a
$2 = {__parent__ = {g_type_instance = {g_class = 0x55555588d4b0}, ref_count = 3, qdata = 0x555555e1ce80}, info = 0x7fffe00124c0, kind = G_FILE_TYPE_REGULAR, gfile = 0x555555dfe160, content_type = 0x555555d85050 "image/jpeg",
  icon_name = 0x0, custom_icon_name = 0x0, display_name = 0x7fffd400b7f0 "p73.jpg", basename = 0x7fffd4011680 "p73.jpg", thumbnail_path = 0x555555e3acc0 "/home/ad/.cache/thumbnails/normal/87903c1cff4c5d32097076c5ddf5686e.png",
  collate_key = 0x7fffd4009070 "S\001\030\001\t\001\001\001\002:73\001\001\001\001MSJ\001\030\030\030\001\t\t\t", collate_key_nocase = 0x7fffd4009070 "S\001\030\001\t\001\001\001\002:73\001\001\001\001MSJ\001\030\030\030\001\t\t\t",
  flags = (THUNAR_FILE_FLAG_THUMB_MASK | THUNAR_FILE_FLAG_IS_MOUNTED)}

(gdb) print *file_b
$3 = {__parent__ = {g_type_instance = {g_class = 0x55555588d4b0}, ref_count = 11, qdata = 0x555555dffd90}, info = 0x0, kind = G_FILE_TYPE_UNKNOWN, gfile = 0x7fffd4010f00, content_type = 0x0, icon_name = 0x0, custom_icon_name = 0x0,
  display_name = 0x0, basename = 0x0, thumbnail_path = 0x0, collate_key = 0x0, collate_key_nocase = 0x0, flags = THUNAR_FILE_FLAG_IS_MOUNTED}

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in thunar (Ubuntu):
status: New → Confirmed
Francisco Villar (villarf) wrote :
Changed in thunar:
importance: Unknown → High
status: Unknown → Confirmed

Tonight my distribution (Debian) made an update of glib2.0 available; I changed from Debian package libglib2.0-0 version 2.46.1-2 to version 2.46.2-1. A quick test revealed that I was not able to cause Thunar to crash by copying many files to a temporary test directory and renaming all of them one at a time.

I did not test exhaustively, so the problem may still exist. I need to get some sleep, but I will do some serious testing in the morning to see if I can get Thunar to crash with the new glib2.0. I will say this -- looking at their changelog, I see at least one commit that sounds promising:

  commit c85bc8bdbce2c5fcec28aa5ef89fee42ffda6474
  Author: Dan Winship <email address hidden>
  AuthorDate: Sat Oct 24 10:37:22 2015 -0400
  Commit: Dan Winship <email address hidden>
  CommitDate: Tue Oct 27 09:51:12 2015 -0400

    gtask: re-fix tasks-blocking-other-tasks

    The new "slowly add more task threads" code doesn't fully deal with
    apps that queue lots and lots of tasks which then block on tasks from
    their task threads. Fix this by bringing back the "task is blocking
    other task" check and making sure that such tasks get bumped to the
    front of the queue.

    https://bugzilla.gnome.org/show_bug.cgi?id=687223

If I am wrong about the problem being fixed, I apologize for getting anyone's hopes up. The simple test I made just now would easily have caused Thunar to crash and disappear before, so I thought I would mention the glib2.0 update so that other people can confirm (or refute) that it helps them.

(In reply to Dave Witbrodt from comment #10)
> Tonight my distribution (Debian) made an update of glib2.0 available; I
> changed from Debian package libglib2.0-0 version 2.46.1-2 to version
> 2.46.2-1. A quick test revealed that I was not able to cause Thunar to
> crash by copying many files to a temporary test directory and renaming all
> of them one at a time.

I was wrong. Thunar is still crashing as before. I must have simply been getting lucky last night, and never triggered the bug.

Sorry for the false hope to anyone reading comment #10.

The workaround I posted in comment #8 survived 1 reboot. After the second reboot Thunar started crashing again. :-[

On #12253 (which is probably a dupe) someone bisected it down to this glib commit:

https://git.gnome.org/browse/glib/commit/?id=779c809a3d07fca6c1da4f87d4ce6cf7f2d95608

This removes a 1 second delay on inotify events, quite possibly triggering race conditions in Thunar.

This is probably also causing #12260

Created attachment 6530
0001-Deactivate-SEND_MOVED-code-paths.patch

For a start, deactivating the SEND_MOVED code paths seems to get rid of the crashes on my system with glib-2.46.2. Please try the patch attached and report back if it fixes the crashes for you too. Why this will not solve the real issue(s), it could give some clues where to look at.

In , ToZ (toz) wrote :

This patch fixes the file rename crash on my system as well (thunar 1.6.10git-87c2b0e and glib2 2.46.1-1). It also seems to fix the other intermittent crash when drag and dropping files/folders (https://bugzilla.xfce.org/show_bug.cgi?id=11983 & https://bugzilla.xfce.org/show_bug.cgi?id=12283).

Test briefly with both "Thunar --deamon" running and not. Will continue testing.

*** Bug 12260 has been marked as a duplicate of this bug. ***

*** Bug 12290 has been marked as a duplicate of this bug. ***

*** Bug 12253 has been marked as a duplicate of this bug. ***

*** Bug 12283 has been marked as a duplicate of this bug. ***

*** Bug 12293 has been marked as a duplicate of this bug. ***

(In reply to Harald Judt from comment #14)
> Created attachment 6530 [details]
> 0001-Deactivate-SEND_MOVED-code-paths.patch
>
> For a start, deactivating the SEND_MOVED code paths seems to get rid of the
> crashes on my system with glib-2.46.2. Please try the patch attached and
> report back if it fixes the crashes for you too. Why this will not solve the
> real issue(s), it could give some clues where to look at.

I think I can also confirm that your patch fixes this problem (Thunar 1.6.10git-a1e7371, glib2 2.46.1-1). No more crashes since then!

Created attachment 6531
Clang's ThreadSanitizer seemingly useful report

I compiled Thunar (1.6.10git-6407141) with clang and -fsanitize=thread and it seems to have found the race that causes these crashes. (It also likes to report a lot of what I assume are false positives; I've left those out.)

*** Bug 12312 has been marked as a duplicate of this bug. ***

I experienced the renaming crash in Thunar with a new installation of
Xubuntu 15.10. I changed the group permissions (right click - properties
- permissions) to 'read and write'. The fault seems to have disappeared
for the moment. If it persists it's an easy fix.

No wait, it only works for folders not for single files!! However, pdf
files in root of documents can now be be renamed without crashing.

I am convinced that this has something to do with permissions in general
as applied from Thunar root - preferences - advanced - permissions

Mike Mc Grath

(In reply to Harald Judt from comment #14)
> Created attachment 6530 [details]
> 0001-Deactivate-SEND_MOVED-code-paths.patch
>
> For a start, deactivating the SEND_MOVED code paths seems to get rid of the
> crashes on my system with glib-2.46.2. Please try the patch attached and
> report back if it fixes the crashes for you too. Why this will not solve the
> real issue(s), it could give some clues where to look at.

I rebuilt Thunar applying this patch, and have been using it for 3 days. I have not had even one crash while renaming, copying, moving, or deleting files. I did a very large amount of renaming today, so I feel confident that Thunar is no longer crashing on renames with this patch applied.

The symptoms mentioned in bug #12297 have also disappeared for me.

Changed in thunar (Ubuntu):
importance: Undecided → High

(In reply to Harald Judt from comment #14)
> Created attachment 6530 [details]
> 0001-Deactivate-SEND_MOVED-code-paths.patch
>
> For a start, deactivating the SEND_MOVED code paths seems to get rid of the
> crashes on my system with glib-2.46.2. Please try the patch attached and
> report back if it fixes the crashes for you too. Why this will not solve the
> real issue(s), it could give some clues where to look at.

This fixed the problem for me as well. It also fixed the other issue mentioned by Dave Witbrodt in #24. Thanks for looking into this bug.

I forgot to mention that I have glib2 version 2.46.2 on Slackware 64bit -current.

I just have noticed something new that could help:
Thunar just crashed while a cron script renamed a file in an open folder.
This indicates that updating the folder view is the problem, not the rename operation.

In , Htd-c (htd-c) wrote :

Hi,
any progress on that one?

I have replicated this bug on todays image xubuntu 16.04 alpha from the xenial-desktop-amd64.iso.

bob (xubuntu-r) wrote :

running thunar from the command line in xenial I get this error:

xubuntu@xubuntu:~$ thunar
Segmentation fault (core dumped)

the crash reported made this claim:
thunar crashed with SIGSEGV in thunar_file_compare_by_name()

bob (xubuntu-r) wrote :

I hope this gets fixed before we have an LTS release. It is pretty embarrassing that a modern file manager cannot rename a file without crashing.

I just replicated this with the latest xubuntu 16.04 beta 2. This is a release intended to flush out the bugs and see if any last problems remain. This is a pretty big and prominent bug which if isn't fixed in the next week or so will be on all the CD images for xubuntu LTS for a year or more.

https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1565319

bob (xubuntu-r) wrote :

it looks like this is seeing some success upstream.
https://bugzilla.xfce.org/show_bug.cgi?id=12264

Paul White (paulw2u) wrote :

In today's 64-bit Xubuntu ISO 20160403:

I renamed a file about 20 times while on the Desktop but using thunar with a path of /home/xubuntu/Desktop - no crash
Moving that file to home/xubuntu/Documents resulted in a crash on the first attempt to rename it.
Moving it to the home directory (/home/xubuntu/) allowed numerous rename attempts without a crash.
Moving the file to Pictures resulted in a crash on the first attempt to rename.
Moving the file to Videos resulted in a crash on the first attempt to rename.
Moving it to /home/xubuntu/ again allowed numerous rename attempts without a crash.

To me it looks like a successful rename is dependent on the location of the file being renamed.

tags: added: xenial
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1512120

tags: added: iso-testing
Pasi Lallinaho (knome) wrote :

Those who have hit this bug before, can you confirm if you are still hitting this bug with the Thunar version on the Xubuntu staging PPA [1] enabled?

[1] https://launchpad.net/~xubuntu-dev/+archive/ubuntu/xubuntu-staging

Paul White (paulw2u) wrote :

@knome, after an extensive testing periodt I'm not seeing thunar crash using the version from the staging PPA.

I'm still seeing bug #1311926 regularly but after 20+ minutes of renaming files in various directories I have not seen thunar crash once.

Samuel (samuel-k-i) wrote :

I just updated to the Thunar version from the staging PPA (1.6.10-2ppa1~15.10).
After renaming a folder 8 times, the folder suddenly appears twice with the exact same name and after renaming one of them, Thunar crashes. The next time Thunar crashed after 4 times renaming, without the the double appearance.

When renaming a file, Thunar also crashes after 4 renamings.

Martin Dauskardt (md001) wrote :

In https://bugzilla.xfce.org/show_bug.cgi?id=12264#c30 there is a patch from thunar developer Harald Judt in comment 30 (2016-02-17 18:17:30 CET ). This patch fixes all my problems with thunar. There was an earlier patch from him (Deactivate-SEND_MOVED-code-paths) which is no longer necessary when thunar is patched with Check-if-a-thunar-file-is-still-valid-before-reloading.patch from comment 30.

Samuel (samuel-k-i) wrote :

Sorry, I dont have the technical ability to apply the patch provided by Harald Judt.
Is this patch not integrated in the version on the staging PPA?
If not, this would probably help to tackle the problem...

Fidelis (rogatum) wrote :

Martin Dauskardt's mentioned mini patch from XFCE's Harald Judt also fixes all Thunar crashes here.

Meaning that the various Thunar bugs – crashes when renaming, when drag & drop, etc - seem to all be related.
But in order to patch you've to compile the Thunar source code for yourself and replace /usr/bin/thunar with the newly compiled binary. Which only some people can do.

Samuel asks, if this patch is included in Pasi's mentioned Xubuntu-PPA ? I don't know.
However, Harald's patch is from February 2016 or newer.
The Xubuntu-PPA's Thunar date says 30 January 2016.
So the PPA's Thunar is older.

Pasi, do you know if the Xubuntu-PPA's Thunar contains Harald's excellent patch?

Samuel (samuel-k-i) wrote :

Probably someone could provide a quick tutorial, similar to
https://forum.xfce.org/viewtopic.php?id=9680
but including the patch from Harald.

I am happy to test the patch, but just don't have the time at the moment to get into this...

information type: Public → Public Security
Samuel (samuel-k-i) on 2016-04-18
information type: Public Security → Private Security
information type: Private Security → Public
Paul White (paulw2u) on 2016-04-28
tags: added: yakkety
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu Package testing tracker.

A list of all reports related to this bug can be found here:
http://packages.qa.ubuntu.com/qatracker/reports/bugs/1512120

tags: added: package-qa-testing

Until this issue is fixed, I created a workaround: a rename shell script invoked through Thunar's custom actions mechanism.

The script needs zenity and xdotool. More information on how to set it up is in the script.

I hope you'll find my junior bash skills useful :)

Please contribute back improved versions.
Let's hope we don't need to use this for long.

@thunar-devs: please fix this bug. It occurs very often, it closes ALL thunar windows and it makes Xfce feel unstable and unfinished. I'm a java dev, so I can't help much.
Thanks for your hard work up until now.

Tim Ritberg (xpert-reactos) wrote :

Will this bug ever be fixed? It is still in 16.04 :-(

Jack Nihil (jnihil) wrote :

Thunar in 16.04 seem worse, but I replaced the binary with what was posted in the link below and I am seeing VERY infrequent occurence of this renaming issue:

https://bugzilla.xfce.org/show_bug.cgi?id=12264#c61

I can't live without Thunar (lots of custom actions), so this post has been a godsend.
Only one rename crash in 3 weeks (I'm sure a lot more if I was doing a lot of file manipulation).

Prahlad Yeri (prahladyeri) wrote :

Can confirm that thunar still crashes occasionally on Xubuntu(Xenial). Voting to fix and resolve this soon (its hight time!).

I can confirm that this bug is still present in Thunar 1.6.10 (build "1.6.10-2ubuntu1").

My OS is 64-bit XUbuntu 16.04 "Xenial" running kernel 4.6-rc7 (build "4.6.0-040600rc7-generic").

I've been looking into the logs is here is the same and only error that's always (repeatedly) generated after every crash:

"PyGIWarning: Wnck was imported without specifying a version first. Use gi.require_version('Wnck', '3.0') before import to ensure that the right version gets loaded.
from gi.repository import GLib, Wnck, GdkX11, Gdk"

The attachment above (comment #54) is my most recent Thunar crash log file.

Daniel (hackie) wrote :

Same here, I see this bug for search already but it was never worse than now, ~10 crashes per day with Xubuntu 16.04 with current updates.

I made the experience that if I select 5 files and move them to another folder, only 4 of them disappear from the view. Then I have to press F5 (refresh) for the 5th file to disappear, if I don't do it, I likely have a crash in the next 10 minutes.

The same thing happens if I rename a file. The old filename is then still in the list sometimes, refreshing helps.

A third thing: If a file gets updated by another program (text editor, current download, git etc.) this could also influence the behaviour of thunar

Benji (benjim) wrote :

I have to bug also with both releases: Xubuntu 16.04 and Xubuntu 15.10

I can confirm that this bug is present in 64-bit XUbuntu 16.04 "Xenial" (kernel version is 4.6.0-040600rc7-generic, Thunar version is 1.6.10-2ubuntu1).

This bug still exists in Xubuntu 16.04.1 amd64 as of today. Thunar is version 1.6.10-2ubuntu1, and the system has all current updates applied. I installed Xubuntu about a week ago and Thunar crashes almost every time I try to rename a file with it. I've started using mv from the terminal to avoid further crashes.

Sean (seanshivak) wrote :

Looks like theres a fix available now on the xfce forum, https://bugzilla.xfce.org/show_bug.cgi?id=12264, is this going to be made available as an update in ubuntu?

I've created a PPA hosting the patched DEB packages that fix this issue for *Ubuntu 16.04:

https://launchpad.net/~yuri-sucupira/+archive/ubuntu/thunar1.6.10-fix

It's available for 32-bit/i386 and 64-bit/amd64 systems, but I haven't tested with other releases.

Sean (seanshivak) wrote :

Thank you for creating the PPA.

You're welcome.

I've been testing the patched DEBs for 5 days already and so far the bug didn't happen. The patch "rename.patch" was introduced by Roy Richardson (https://bugzilla.xfce.org/show_bug.cgi?id=12264#c114), then I picked the patch, applied it to Thunar's original source-code and then created and signed the patched version that I uploaded to the PPA. Hope it helps other Xenial users.

Nosphky (philip-jackson) wrote :

I've been having the Thunar shutting down problem ever since I made a clean install of UbuntuStudio 16.04.1 about 3 weeks' ago. Also from time to time, Thunar would fail to display some files or to remove some files which were dragged and dropped into a directory.

I have installed the patched DEB packages from the PPA created by Yuri Ribeiro Sucupira, see #62 above.

Since installing, I've renamed over 30 files without any problem so far. I've also dragged and dropped files from one directory to another and back again without display problems.

So, the outlook does appear hopeful for Ubuntu 16.04 LTS releases with xfce.

Marcos (wstlmn) on 2016-09-30
Changed in thunar (Ubuntu):
assignee: nobody → Marcos (wstlmn)
Dani (damufo) wrote :

This bug still exists in Xubuntu 16.04.1 amd64 as of today. Thunar is version 1.6.10-2ubuntu1, and the system has all current updates applied.

Si Dedman (si-dedman) wrote :

still present in 16.10 with thunar 1.6.10 also.

cyrille borne (cyrille) wrote :

same here in Xubuntu 16.10

@Dani (damufo), @Si Dedman (si-dedman) and @cyrille borne (cyrille): isn't the issue solved after you add the PPA below and run the APT "update" and "dist-upgrade" commands (as explained at the PPA)?

https://launchpad.net/~yuri-sucupira/+archive/ubuntu/thunar1.6.10-fix

Si Dedman (si-dedman) wrote :

My bad, I hadn't but have now. Thanks.

Lucho Nacho (livalenz) wrote :

@Yuri. I confirm that the patch fixes the problem.

Lucho Nacho (livalenz) wrote :

And forgot to say thank you!

dnord (dnord) wrote :

Unfortunately fix from ppa:yuri-sucupira/thunar1.6.10-fix introduces new bug: thunar occasionally freezes on mount events.

John Carmack (john.carmack) wrote :

Thunar 1.6.10-4 still crashes during moving files, drag-and-drop, cut-and-paste and renaming. This has been going on since 2015. It makes Thunar completely unusable, please fix this!!!

Sylvain Viart (sylvain-viart) wrote :

Got it on xubuntu 16.10, still here.

And duplicate bug n° is wrong in https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1621944

Norman (normal-norman) wrote :

It's a shame that Xfce devs can't fix this bug since 2015. Time to switch to MATE.

It's true. I got out the XFCE because the most errors in the your graphical inteface.

    Em Segunda-feira, 16 de Janeiro de 2017 14:16, Norman <email address hidden> escreveu:

 It's a shame that Xfce devs can't fix this bug since 2015. Time to
switch to MATE.

--
You received this bug notification because you are subscribed to a
duplicate bug report (1603030).
https://bugs.launchpad.net/bugs/1512120

Title:
  thunar crashes on file renaming

Status in thunar:
  Confirmed
Status in thunar package in Ubuntu:
  Confirmed

Bug description:
  When renaming files in a folder while re-sorting similarly named
  files, thunar crashes fairly often. Apport does not detect the
  crashes.

  Running thunar in valgrind produces these log entries in the moment of
  the crash:

  ==28859== Thread 1:
  ==28859== Invalid read of size 1
  ==28859==    at 0x04c2ffd3: strcmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==28859==    by 0x0014590c: thunar_file_compare_by_name (within /usr/bin/thunar)
  ==28859==    by 0x00153e3d: thunar_list_model_cmp_func (within /usr/bin/thunar)
  ==28859==    by 0x07e4da23: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.1)
  ==28859==    Address 0x0 is not stack'd, malloc'd or (recently) free'd
  ==28859==
  ==28859== Process terminating with default action of signal 11 (SIGSEGV)
  ==28859== Access not within mapped region at address 0x0
  ==28859==    at 0x04c2ffd3: strcmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==28859==    by 0x0014590c: thunar_file_compare_by_name (within /usr/bin/thunar)
  ==28859==    by 0x00153e3d: thunar_list_model_cmp_func (within /usr/bin/thunar)
  ==28859==    by 0x07e4da23: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.1)
  ==28859==    If you believe this happened as a result of a stack
  ==28859==    overflow in your program's main thread (unlikely but
  ==28859==    possible), you can try to increase the size of the
  ==28859==    main thread stack using the --main-stacksize= flag.
  ==28859==    The main thread stack size used in this run was 8388608.
  ==28859==
  ==28859== HEAP SUMMARY:
  ==28859== in use at exit: 11,169,056 bytes in 101,668 blocks
  ==28859== total heap usage: 8,917,549 allocs, 8,815,881 frees, 736,520,410 bytes allocated
  ==28859==
  ==28859== For counts of detected and suppressed errors, rerun with: -v
  ==28859== Use --track-origins=yes to see where uninitialised values come from
  ==28859== ERROR SUMMARY: 1046 errors from 45 contexts (suppressed: 0 from 0)
  ==28859==

  ProblemType: Bug
  DistroRelease: Ubuntu 15.10
  Package: thunar 1.6.10-1
  ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3
  Uname: Linux 4.2.0-16-generic x86_64
  ApportVersion: 2.19.1-0ubuntu4
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Sun Nov  1 18:57:09 2015
  InstallationDate: Installed on 2015-02-05 (268 days ago)
  InstallationMedia: Xubuntu 15.04 "Vivid Vervet" - Alpha amd64 (20150205)
  SourcePackage: thunar
  UpgradeStatus: Upgraded to wily on 2015-05-28 (156 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/thunar/+bug/1512120/+subscriptions

Thought this might help someone who knows Thunar better than I do figure out this bug. When I ran the Xubuntu Thunar test 1512120 on a desktop running XUbuntu 16.04 64 bit on a Dell GX620, not only does Thunar crash, but when Thunar refreshes, it doesn't always show filename changes, and sometimes when Thunar updates, some files don't display (as if the update information was collected while filenames were being changed, instead of after). When I compiled Thunar 1.6.10 and then used the Thunar-1.6.10.patch that I found on line, the crashes stopped, but the other symptoms did not.

What might be important is that when I run XUbuntu 16.04 64 bin in VirtualBox on an old MacBook Pro, none of the symptoms occur.

Changed in thunar:
status: Confirmed → Fix Released
Kenneth Wrede (kennethwrede) wrote :

This is a compiled version of the latest sources of today, Thunar 1.6.11 from 13 Feb 2017. Default options.
1) Remove your old version.
2) Install this one.
3) Restart the system.
4) Try to make it crash and see if it works for you as well.

It haven't crashed for me, seems to work.
I don't know if the patched version in future will replace this one, or if you have to change back manually if you want it.

This kind of bug is critical to many users of XFCE. We are stuck with the last "stable" Xubuntu LTS 14.04 while it is running close to EOL.

**********
TO MAINTAINERS OF XUBUNTU
I don't know how hard it is to solve such a problem. But the desktop on a LTS must work after almost a year in the wild.

In the future, Please consider to offer an older but working version as an alternative if the bleeding edge is to bleeding.

Anyway! Thanks for the time you are spending on the system!

Kenneth Wrede (kennethwrede) wrote :

About the compiled Thunar version 1.6.11 above.

You are better of if you install the new version over the old one. Then it will replace the current one without removing other packages as a side effect. (thunar-volman and a few more.)

Sean Davis (bluesabre) wrote :

This bug was fixed with the thunar 1.6.11 upload to zesty.

thunar (1.6.11-0ubuntu1) devel; urgency=medium

  * New upstream bugfix release.
    - Drop patches from upstream.

 -- Unit 193 <email address hidden> Wed, 15 Feb 2017 16:47:31 -0500

Changed in thunar (Ubuntu Zesty):
status: Confirmed → Fix Released
Sean Davis (bluesabre) on 2017-02-21
description: updated
Sean Davis (bluesabre) on 2017-02-22
summary: - thunar crashes on file renaming
+ [SRU] thunar crashes on file renaming
Sean Davis (bluesabre) wrote :

Package versions 1.6.11-0ubuntu1.16.04.1 and 1.6.11-0ubuntu1.16.10.1 have been uploaded to xenial-proposed and yakkety-proposed respectively. These packages will be evaluated as stable release updates as outlined here:

https://wiki.ubuntu.com/StableReleaseUpdates

Changed in thunar (Ubuntu Xenial):
status: New → In Progress
Changed in thunar (Ubuntu Yakkety):
status: New → In Progress
Changed in thunar (Ubuntu Xenial):
assignee: nobody → Sean Davis (bluesabre)
Changed in thunar (Ubuntu Yakkety):
assignee: nobody → Sean Davis (bluesabre)
Łukasz Zemczak (sil2100) wrote :

The contents of the uploads look ok but the version numbers for the SRUs are wrong (the SRU version number should always be smaller than the released devel version, so it needs to be 1.6.11-0ubuntu0.16.04.1 etc.) - but now worries, I'll correct those myself before doing the final queue approval. This microrelease fixes a few more bugs and doesn't carry proper autopkgtesting so I'll need to reach out to a TB member for a green light (possibly).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.