[SRU] thunar crashes on file renaming

[Daniel Kessel]

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

[Hondaran (hondaran)]

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.

[Hjudt-l (hjudt-l)]

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.

[Hondaran (hondaran)]

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

[Hondaran (hondaran)]

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)

[Rafael Gattringer (rafael.gattringer)]

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.

[mrsfixit (mrsfixit)]

(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... :-/

[mrsfixit (mrsfixit)]

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.

[Flo-xfce (flo-xfce)]

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.

[mrsfixit (mrsfixit)]

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.

[Dawitbro (dawitbro)]

(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}

[Launchpad Janitor (janitor)]

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

[Francisco Villar (villarf)]

Related bug in xfce project: https://bugzilla.xfce.org/show_bug.cgi?id=12264

[Dawitbro (dawitbro)]

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.

[Dawitbro (dawitbro)]

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

[mrsfixit (mrsfixit)]

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

[Alistair Buxton (a-j-buxton)]

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

[Hjudt-l (hjudt-l)]

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.

[ToZ (toz)]

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.

[Hjudt-l (hjudt-l)]

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

[Hjudt-l (hjudt-l)]

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

[Hjudt-l (hjudt-l)]

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

[Hjudt-l (hjudt-l)]

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

[Hjudt-l (hjudt-l)]

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

[Hondaran (hondaran)]

(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!

[Evangelos Foutras (foutrelis)]

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

[Hjudt-l (hjudt-l)]

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

[mpcmcgrath (mpcmcgrath)]

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

[Dawitbro (dawitbro)]

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

[Slackph (slackph)]

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

[Slackph (slackph)]

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

[Martin Matuska (mm-vx)]

The xfce commit 029012f4 fixed the rename crash on my system.
http://git.xfce.org/xfce/thunar/commit/?id=029012f4c39d9d3d9ae617491a69f76f54a4192f

[Markus-naeher (markus-naeher)]

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.

[Htd-c (htd-c)]

Hi,
any progress on that one?

[bob (xubuntu-r)]

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

[bob (xubuntu-r)]

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

[Tim Ritberg (xpert-reactos)]

Bug fixed in Thunar, but when in Ubuntu??

http://www.linuxquestions.org/questions/slackware-14/thunar-1-6-10-crashes-randomly-while-renaming-files-64bit-current-4175560072/

[bob (xubuntu-r)]

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

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

[Paul White (paulw2u)]

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.

[Slumbergod-n (slumbergod-n)]

I am sick to death of a$$holes who contribute nothing useful coming on here and criticising others for making an effort to get this bug fixed. You guys have no manners and act like you own the world but I don't see any of your contributions. This is the problem with linux. It is infected with a$$holes who flame everyone. Get a life asshole and let the rest of us try to identify and fix the bug that you are too useless to fix.

[Slumbergod-n (slumbergod-n)]

Hey Peter why don't you remove yourself from all these bug reports and do the rest of us a favour.

[Peter Feichtinger (shippo)]

Wow, I didn't expect that.
I was not at all trying to be rude and I'm sorry if I offended anyone. It's just that commenting on this bug with another problem doesn't help anyone either.

@slumbergod: Looking at your comment you are not allowed to talk about manners, at all. I mean come on, calling someone an asshole because they step on your toes somehow, that's rude; what I wrote was not.

[Kip Warner (kip)]

Ok gents, let's all just chill and return to focusing on the issue at hand.

[Martin-dauskardt (martin-dauskardt)]

What slumbergod reported is absolutely on-topic. The problems he and Yuri were writing about are known side-effect of an earlier patch (which we all hoped that it could be a solution for the renaming/remove crash.)
The side effects with this patch (when accessing USB drives and other file systems) have already been reported in #131 and #136.
Obviously Peter wasn't aware of the whole story.

[Patrice (patrice-dum-0)]

I would like to confirm this bug which I noticed.

xUbuntu 16.10 / AMD64
xfce 4.12.0-2 ubuntu

Thunar crashes about every 3 or 4 file rename !

Error : Segmentation fault (core dumped)

[Pgkos-bugzilla (pgkos-bugzilla)]

Created attachment 6965
Fix race in thunar_file_rename and thunar_folder_monitor

[Pgkos-bugzilla (pgkos-bugzilla)]

I am sending a simple patch which wraps the renaming code and the folder monitor code in a mutex.

I suppose that the main reason for the crash is that when we call in thunar-file.c:1932:

g_file_set_display_name (file->gfile, name, cancellable, error);

this call sends a signal which is connected to the folder monitor. The folder monitor runs on another thread. The thunar_folder_monitor function gets called immediately and it sends some signals which call thunar_list_model_files_added, which then uses thunar_file_compare_by_name as comparison function.

The problem is, we have our original, "renaming" thread, which at one point calls thunar_file_info_clear. If we are at the end of this clearing function and then the thread switches and the code from thunar_file_compare_by_name continues, it will segfault because all members of ThunarFile structure are now null.

The solution is to prevent starting the code of thunar_folder_monitor until the renaming procedure is completed so all ThunarFile members are already updated.

So, I have added an extern "rename" mutex which is acquired in these two functions.

The mutex must be acquired before the call to g_file_set_display_name.

Also, there is a simple method to trigger the segfault:
- add a 1-second sleep as the last line of the thunar_file_info_clear function
- add a 0.5-second sleep as the first line of the thunar_folder_monitor
(you can add some conditional checks to prevent long pause when loading Thunar)
- compile and test

[Martin-dauskardt (martin-dauskardt)]

@ pgkos:

Which version of thunar was the base for this patch?

-1.6.10 vanilla?

-1.6.10 with patches from Distribution?
(1.6.10 in Xubuntu 16.10 has for example some additional patches, including the
Check-if-a-thunar-file-is-still-valid-before-reloading.patch from 17.02.2016 from Harald Judt, which is not in master git.

-git master branch?

[Pgkos-bugzilla (pgkos-bugzilla)]

@Martin Dauskardt

The patch is based on the git master.

[Yomito (yomito)]

Mint 18 XFCE just updated to 18.1 here. Still with Thunar 1.6.10-3mint1. Still working like a charm. No problem moving files between folders. No problem renaming files. Mint team got the answer to your problems.

[Z-spam-b (z-spam-b)]

Mint applies 4 patches to Thunar in 1.6.10-3mint1:

0001-Don-t-copy-templates-but-create-them-bug-8312.patch (bug #8312)
01_support-non-multiarch-modules.patch (related to loading modules on different architectures, not related to this bug)
02_Fix-crashes-when-reloading-target-file-after-move.patch (bug #11983 which seems to be similar to this one)
03_Fixing-missing-return-value-in-standard-view.patch (IMHO unrelated)

02_* and 03_* are already in git master.

[Simon Steinbeiß (ochosi)]

(In reply to pgkos.bugzilla from comment #155)
> I am sending a simple patch which wraps the renaming code and the folder
> monitor code in a mutex.
>
> I suppose that the main reason for the crash is that when we call in
> thunar-file.c:1932:
>
> g_file_set_display_name (file->gfile, name, cancellable, error);
>
> this call sends a signal which is connected to the folder monitor. The
> folder monitor runs on another thread. The thunar_folder_monitor function
> gets called immediately and it sends some signals which call
> thunar_list_model_files_added, which then uses thunar_file_compare_by_name
> as comparison function.
>
> The problem is, we have our original, "renaming" thread, which at one point
> calls thunar_file_info_clear. If we are at the end of this clearing function
> and then the thread switches and the code from thunar_file_compare_by_name
> continues, it will segfault because all members of ThunarFile structure are
> now null.
>
> The solution is to prevent starting the code of thunar_folder_monitor until
> the renaming procedure is completed so all ThunarFile members are already
> updated.
>
> So, I have added an extern "rename" mutex which is acquired in these two
> functions.
>
> The mutex must be acquired before the call to g_file_set_display_name.
>
> Also, there is a simple method to trigger the segfault:
> - add a 1-second sleep as the last line of the thunar_file_info_clear
> function
> - add a 0.5-second sleep as the first line of the thunar_folder_monitor
> (you can add some conditional checks to prevent long pause when loading
> Thunar)
> - compile and test

While your patch may prevent the crash it also seems to inhibit refreshing of the folder contents. Concretely, thunar seems to get stuck in the refresh thread.

For the future and anyone trying to help with fixing this: if your patch does not pass the testcase linked here, it's not really fixing it.
http://packages.qa.ubuntu.com/qatracker/milestones/361/builds/117794/testcases/1681/results

Please note that you have to run the rename loop in your terminal for a while in order to expose the race condition.

[Yomito (yomito)]

Six boring minutes watching Simon Steinbeiss' test (comment 160) working on Thunar 1.6.10-3mint1 (Mint Xfce 18.1).
During all the time the files changed their names with no problem at all.

[Pgkos-bugzilla (pgkos-bugzilla)]

@Simon Steinbeiss

My patch only prevents the crash, it does not affect the hanging at all - Thunar also hangs during your test without my patch.

The hanging is a distinct issue.

If I have time I will try to fix that issue as well.

[Xfce-d (xfce-d)]

pgkos.bugzilla basically did, what I proposed at comment #95 half a year ago: He identified the critical sections and implemented synchronization to prevent the race condition. And that's exactly the right way to fix this bug! If pgkos.bugzilla determined the CS right, the rest should be a child's play.

However, Simon is right, too: pgkos.bugzilla's implementation slowdowns the execution of Thunar or may even make it hang. This is because the patch allows only one thread to execute thunar_folder_monitor() concurrently.

This problem is well-known as the "Readers-Writers-Problem". The solution is simple and described in detail here [0, pp.69].

Basically an int and another mutex is needed inside thunar/thunar-folder.c, to better orchestrate entry into thunar_folder_monitor() and thus re-enable parallel execution of it.

I am sure we are only a small step away from getting this annoying bug finally fixed =)

[0] http://greenteapress.com/semaphores/LittleBookOfSemaphores.pdf

[Pgkos-bugzilla (pgkos-bugzilla)]

@<email address hidden> - thank you for the suggestions. Regarding the hangs, I'm pretty certain that the hanging is not caused by my mutex - thunar_folder_monitor is always called on the main thread (it is a slot function). Also, I have experienced the same hang without the mutex.

[Pgkos-bugzilla (pgkos-bugzilla)]

Unfortunately, I have spotted yet another multithreading bug (I have verified it in gdb).

Basically, thunar_file_finalize function in thunar-file.c is not thread safe.

The reason why this function is bad is that when gobject's reference count reaches 0 (inside Glib's g_object_unref, see https://git.gnome.org/browse/glib/tree/gobject/gobject.c#n3177), thunar_file_finalize is not yet invoked. So, there is a possibility that another thread will get a file from the cache (hashtable), but that file already has a refcount == 0.

In particular, thunar_file_finalize conflicts with thunar_file_cache_lookup. For example, the following order of events will cause undefined behavior:

ThunarFile's refcount reaches 0 --> another thread calls thunar_file_cache_lookup and gets an invalid pointer to just-being-destroyed ThunarFile --> ThunarFile gets removed from the hashtable (too late).

I am investigating the possible solutions (https://github.com/jlindgren90/thunar/commit/9c6dbb1dae70 looks promising).

[Pgkos-bugzilla (pgkos-bugzilla)]

The hangs may be caused by the multithreading bug from my previous comment.

The problem is this: there is both a folder monitor and a file monitor. Usually, the file monitor is registered before the folder monitor. If that happens, when a file is renamed, the file monitor gets called and the folder monitor gets temporarily disconnected (this causes thunar_folder_monitor not to run later).

But, sometimes, when we're out of luck, because of the multithreading issues, the file monitor is not registered (or registered for the wrong (already renamed?) filename). In that case, the folder monitor will handle the signal.

When that happens, this assertion always fails in thunar_folder_finished - this causes the hang:
_thunar_return_if_fail (folder->content_type_idle_id == 0);

[Pgkos-bugzilla (pgkos-bugzilla)]

Created attachment 6976
Fix crash and hang while renaming

A new version of my patch. This fixes both:
- the crash when renaming a file through the popup dialog
- the hang when renaming many files at once (e.g. using mv)

For the remaining crashes (while using mv command), please apply https://github.com/jlindgren90/thunar/commit/9c6dbb1dae70.

[Yves-Alexis Perez (corsac)]

(In reply to pgkos.bugzilla from comment #167)
> Created attachment 6976 [details]
> Fix crash and hang while renaming
>
> A new version of my patch. This fixes both:
> - the crash when renaming a file through the popup dialog
> - the hang when renaming many files at once (e.g. using mv)
>
> For the remaining crashes (while using mv command), please apply
> https://github.com/jlindgren90/thunar/commit/9c6dbb1dae70.

Thanks for the patch, I'll try to test it for Debian (although it doesn't apply at first sight on 1.6.10 so I'll try a backport)

[Simon Steinbeiß (ochosi)]

@yves-alexis: Both patches apply cleanly on master.

@pgkos: So far the test-case passes (had it run for >10mins), so nice work there!

[Simon Steinbeiß (ochosi)]

(In reply to Simon Steinbeiss from comment #169)
> @yves-alexis: Both patches apply cleanly on master.
>
> @pgkos: So far the test-case passes (had it run for >10mins), so nice work
> there!

Having had this test-case running for >1hr I ran into an issue (may well be a different problem/bug)

(lt-thunar:7709): thunar-WARNING **: Content type loading failed for 10.txt.txt: Error when getting information for file '/tmp/10.txt.txt': No such file or directory

[Simon Steinbeiß (ochosi)]

(In reply to Simon Steinbeiss from comment #170)
> (lt-thunar:7709): thunar-WARNING **: Content type loading failed for
> 10.txt.txt: Error when getting information for file '/tmp/10.txt.txt': No
> such file or directory

Ignore the above comment, it's not relevant and was erroneously posted (mixed up terminal tabs).

[Kev Bowring (flocculant)]

Been running git thunar with 2 patches (9c6dbb1dae70.patch and fix_crash.patch)

Hadn't up till now seen any problems previously noted.

However doing the following I have had thunar crash 2 out of 3 times doing so - 2nd and 3rd times trying to get a backtrace (thunar hung AND gdb hung doing the second)

Files and folders being moved consisted of 4 folders with 1 sub-folder and 2 sub-sub folders within that. Total was ~21Gb in 16 iso's.

1 - open origin
2 - open destination in tab
3 - copy folders to destination
4 - delete from origin
5 - move from destination back to origin

at the point where it had moved the final iso it crashed.

Investigating following crash 1 of the 2 sub-sub-folders remained in the destination folder.

Contents of the backtrace from the second crash when gdb hung:

GNU gdb (Ubuntu 7.12-0ubuntu4) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from thunar...done.
(gdb) handle SIG33 pass nostop noprint
Signal Stop Print Pass to program Description
SIG33 No No Yes Real-time event 33
(gdb) set pagination 0
(gdb) run
Starting program: /usr/local/bin/thunar
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffedb38700 (LWP 9198)]
[New Thread 0x7fffed337700 (LWP 9199)]
[New Thread 0x7fffe7fff700 (LWP 9201)]
[New Thread 0x7fffe6b27700 (LWP 9203)]
[Thread 0x7fffe6b27700 (LWP 9203) exited]
[New Thread 0x7fffe6b27700 (LWP 9205)]
[Thread 0x7fffe6b27700 (LWP 9205) exited]
[New Thread 0x7fffe6b27700 (LWP 9282)]
[Thread 0x7fffe7fff700 (LWP 9201) exited]
[New Thread 0x7fffe7fff700 (LWP 9286)]
[New Thread 0x7fffe4fb1700 (LWP 9321)]
[Thread 0x7fffe4fb1700 (LWP 9321) exited]

(thunar:9194): thunarx-CRITICAL **: thunarx_menu_provider_get_folder_actions: assertion 'thunarx_file_info_is_directory (folder)' failed

(thunar:9194): thunarx-CRITICAL **: thunarx_menu_provider_get_folder_actions: assertion 'thunarx_file_info_is_directory (folder)' failed
**
thunar:ERROR:thunar-file.c:3929:thunar_file_unwatch: code should not be reached

Thread 1 "thunar" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
58 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb)

Contents of the final backtrace:

GNU gdb (Ubuntu 7.12-0ubuntu4) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There ...

[Pgkos-bugzilla (pgkos-bugzilla)]

Created attachment 6978
Fix crash and hang while renaming (2)

@flocculant I have updated the patch - please test.

[Yuri Ribeiro Sucupira (yuri-sucupira)]

"Comment 78 for bug 1512120

Kent Lion (klsu) wrote 50 minutes ago: #78

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

[source: https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1512120/comments/78]

[Kev Bowring (flocculant)]

@pgkos:

I've got thunar built with your new patch and the git one from a ppa.

Moving the same files as before I had no crashes.

Then I redid the same test, this time copying the files to 2 seperate locations on seperate drives.

Thunar crashed.

[Pgkos-bugzilla (pgkos-bugzilla)]

(In reply to flocculant from comment #175)
> @pgkos:
>
> I've got thunar built with your new patch and the git one from a ppa.
>
> Moving the same files as before I had no crashes.
>
> Then I redid the same test, this time copying the files to 2 seperate
> locations on seperate drives.
>
> Thunar crashed.

@flocculant, please apply only:

- my patch
- https://github.com/jlindgren90/thunar/commit/9c6dbb1dae70.patch

and retest.

I cannot reproduce this bug. Please, if possible, attach a gdb backtrace.

[Kev Bowring (flocculant)]

Sorry - my previous post might have read confusingly.

The ppa version has your patch and 9c6dbb1dae in it.

Since then I've had thunar crash on me moving 1 file.

[Kev Bowring (flocculant)]

Had no luck getting a backtrace I'm afraid.

This is what I've done today.

sda - copying 26Gb to sdc and sdd

sdc - copying 50Gb to sda

sdd - copying 30Gb to sda

sdd - running the txt to txt.txt from comment #32 with a sleep of 0.25

Detached tabs as soon as a task was in progress

I ran this 3 times without a crash.

I then remembered that at some point over the last 2 or 3 days while I've been testing this I turned off the showing of thumbnails.

I turned that back on and reran the test.

Thunar then crashed.

Whether that is coincidental or not I can't answer.

[Kev Bowring (flocculant)]

Note:

sda - copying 26Gb to sdc and sdd - This task failed with 11Gb being copied to sdc and 10Gb to sdd

sdc - copying 50Gb to sda - This task completed.

sdd - copying 30Gb to sda - This task completed.

txt to txt.txt kept running seemingly without error (killed thunar and restarted it - went to relevant folder and the files were still changing back and forth)

[Vlado-chren (vlado-chren)]

Hello.

Patch #6978 solves the renaming issue for me - I couldn't crash thunar using steps which used to crash it before.

@flocculant's crashes with moving files (comment #172) is just different issue / bug.

[Simon Steinbeiß (ochosi)]

Hi again everyone,

I have pushed the two commits that resolve this particular issue (remember: this bugreport is about renaming a single file in a directory, there were just a lot of parallel reports in here).

This will help to establish a new baseline which people can test and report bugs against, if they find them. I will also evaluate the patch which (hopefully) fixes moving, which is what e.g. flocculant reported.

This issue is becoming too long to read anyway and it's very hard to extract the really useful stuff.

For reference, here are the commits:
https://git.xfce.org/xfce/thunar/commit/?id=b838a4d250e3283590cabac2ee5947cdf91c8864
https://git.xfce.org/xfce/thunar/commit/?id=35e65ab0ed5675b2dc7b4224b0ad152df3c3e9b0

[Yomito (yomito)]

Fix released (Thunar 1.6.11-0ubuntu1):

https://launchpad.net/ubuntu/+source/thunar

Compiled version (comment #80):

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

[Yuri Ribeiro Sucupira (yuri-sucupira)]

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

[Alistair Buxton (a-j-buxton)]

There seems to be a problem with the patch for this bug - namely that it now deadlocks instead of crashing.

The problem appears to be as follows:

1. A file in that directory gets renamed.
2. G_FILE_MONITOR_EVENT_MOVED happens on thread A.
3. The mutex gets locked.
4. The thumbnail associated with the file gets renamed.
5. G_FILE_MONITOR_EVENT_MOVED happens for the thumbnail on thread B.
6. Thread B waits on the mutex to unlock.
7. Thread A won't unlock the mutex until thread B finished.

This all seems to be a result of:

  thunar_file_move_thumbnail_cache_file (event_path, other_path);

now being inside the mutex. The previous crash was likely caused by a similar chain of events, eg check out this bug report which specifically mentions move_thumbnail:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800723;msg=91

[Yanpas (yanpaso)]

I agree with comment #184. I face an app being frozen in event loop. Do we need to open a new bug?

[Main-haarp (main-haarp)]

(In reply to Yan Pas from comment #185)
> I agree with comment #184. I face an app being frozen in event loop. Do we
> need to open a new bug?

Yes, please do and let us know the bug number.

[Simon Steinbeiß (ochosi)]

There already is a bugreport for the problem you mention (which is not this bug, but a separate one).
Please don't comment on old and closed bugreports, use the browse or search functions of bugzilla instead.

Anyway, here's the link to the new bugreport (which already has a patch ready for testing)
https://bugzilla.xfce.org/show_bug.cgi?id=13481