[SRU] thunar crashes on file renaming

Bug #1512120 reported by Daniel Kessel on 2015-11-01
666
This bug affects 131 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.

9 comments hidden view all 101 comments
Daniel Kessel (dkessel) wrote :
tags: added: xubuntu
summary: - crashes on file renaming
+ thunar crashes on file renaming
10 comments hidden view all 101 comments

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}

10 comments hidden view all 101 comments

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
10 comments hidden view all 101 comments

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

1 comments hidden view all 101 comments

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

1 comments hidden view all 101 comments

(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
tags: added: iso-testing
Samuel (samuel-k-i) on 2016-04-18
information type: Public → Public Security
information type: Public Security → Private Security
information type: Private Security → Public
Paul White (paulw2u) on 2016-04-28
tags: added: yakkety
tags: added: package-qa-testing
21 comments hidden view all 101 comments

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
1 comments hidden view all 101 comments
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).

Hello Daniel, or anyone else affected,

Accepted thunar into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/thunar/1.6.11-0ubuntu0.16.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in thunar (Ubuntu Yakkety):
status: In Progress → Fix Committed
tags: added: verification-needed
Changed in thunar (Ubuntu Xenial):
status: In Progress → Fix Committed
Łukasz Zemczak (sil2100) wrote :

Hello Daniel, or anyone else affected,

Accepted thunar into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/thunar/1.6.11-0ubuntu0.16.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Kev Bowring (flocculant) wrote :

Updated to Thunar 1.6.11 in 16.04.

Fixes the bug for me.

tags: added: verification-done
removed: verification-needed
Kev Bowring (flocculant) wrote :

Updated to Thunar 1.6.11 in 16.10.

Fixes the bug for me.

verification tag left as -done

Stulrich (stulrich) wrote :

Updated to the newly proposed Thunar 1.6.11 in Xubuntu 16.04.2 .

Fixes the bugs for me, too: in contrast to Thunar 1.6.10 it now works when renaming files _and_ when moving files across partition boundaries.

Looks good to me. Thanks to all who contributed!

Will (lightningw9) wrote :

I have been testing 1.6.11 in Xubuntu 16.04, moved a lot of files this week and no crashes. Thunar is much better to use again now.

I noticed a new bug in 1.6.11 although it is minor compared to the problems with 1.6.10, this issue is already reported here: https://bugzilla.xfce.org/show_bug.cgi?id=13364

I love XFCE, just wish we could get a few more developers, thanks to everyone that worked on this fix.

N H (thenh813) wrote :

My OS is Ubuntu 16.04, with XFCE version 4.12.1 installed, Thunar version 1.6.10, which is the latest available in the repositories. All updates are installed. I'm experiencing this issue multiple times a day.

sudo apt-get install thunar
Building dependency tree
Reading state information... Done
thunar is already the newest version (1.6.10-2ubuntu1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

If it's fixed in 1.6.11 on Xubuntu 16.04, the patch should be present on ALL versions of Ubuntu.

I experience this bug at least 5-10 times per day, sometimes a lot more when working on projects with lots of files that have similar names. It does happen often enough just renaming other files, like maybe a 1 in 20 chance, but I have yet to loose data as it has successfully renamed all of them. It crashes so much when working on said projects though, that I'v actually went to using the terminal using "for i in filename*" loops wiht various regex matches and the cut command to mass rename files instead of Thunar.

I will be building Thunar from the latest source and overwriting the system version to see if that fixes it, as it appears regular Ubuntu dosen't have the latest version of Thunar in the repos. Someone please get this fixed asap.

Kev Bowring (flocculant) wrote :

@ thenh813 - the idea is for people using 16.04 and/or 16.10 to test the package in -proposed so the new version can be release to those people.

To those interested in testing the proposed Thunar 1.6.11 but don't know how to build the package from the source code: I've created a PPA here:

https://launchpad.net/~yuri-sucupira/+archive/ubuntu/thunar1.6.11-proposed

Just follow the instructions there and see if the new version runs smoothly.

Kev Bowring (flocculant) wrote :

@ yuri-sucupira - You don't need to build the package ... enable -proposed, either upgrade or reinstall thunar - you'll get the new package.

@flocculant I wasn't aware of that. Thanks for the clarification. :)

I've just deleted the PPA so far hosted at

https://launchpad.net/~yuri-sucupira/+archive/ubuntu/thunar1.6.11-proposed

...and then I updated the instructions I had put at

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

...in order to explain to the other users how to remove my "thunar1.6.10-fix" PPA, enable the "proposed" PPA and then upgrade Thunar to the proposed version 1.6.11.

Thank you all for helping making Thunar great again. :)

I'm kinda regretting having deleted my "thunar1.6.11-proposed" PPA: by enabling the "proposed" repository, the average user may accidentally execute something like "sudo apt-get dist-upgrade" and then upgrade not only Thunar but his/her ***entire system*** with all the testing/proposed packages, which may be dangerous or at least not desireable as a "general rule".

Installing only Thunar packages from a separate PPA like my (now deleted) "thunar1.6.11-proposed" was a "safer" approach.

Anyway... Instead of creating another "proposed" PPA, I decided to update the text/description at my "thunar1.6.10-fix" PPA hosted at

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

...with instructions on how to:
(1) Enable the "proposed" PPA;
(2) Upgrade ***only*** Thunar; and
(3) Then disable the "proposed" PPA, for the sake of safety/stability.

N H (thenh813) wrote :

Both building from source and the version in proposed fix the issue. I'l stick with the version in proposed then, as when I built from source I just used make install to overwrite the old versions. I suppose leaving the system thinking it's still on a older version (according to apt/dpkg) and having newer files is bad. To be honest I was just too lazy to make a .deb package. Thanks for the tip about proposed and I'l remember that for applications that have patched bugs in the future.

Kev Bowring (flocculant) on 2017-03-14
tags: added: verification-done-xenial verification-done-yakkety
removed: verification-done
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package thunar - 1.6.11-0ubuntu0.16.04.1

---------------
thunar (1.6.11-0ubuntu0.16.04.1) xenial; urgency=medium

  * No change backport to xenial
    - Fixes crash on move and rename (LP: #1512120)

 -- Sean Davis <email address hidden> Tue, 21 Feb 2017 20:38:10 -0500

Changed in thunar (Ubuntu Xenial):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for thunar has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package thunar - 1.6.11-0ubuntu0.16.10.1

---------------
thunar (1.6.11-0ubuntu0.16.10.1) yakkety; urgency=medium

  * No change backport to yakkety
    - Fixes crash on move and rename (LP: #1512120)

 -- Sean Davis <email address hidden> Tue, 21 Feb 2017 20:24:10 -0500

Changed in thunar (Ubuntu Yakkety):
status: Fix Committed → Fix Released
Displaying first 40 and last 40 comments. View all 101 comments or add a comment.
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.