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

[Gabriele-tozzi-c (gabriele-tozzi-c)]

It happens to me too. Please let me know if you need more info.

[Hjudt-l (hjudt-l)]

Created attachment 6613
Check-if-a-thunar-file-is-still-valid-before-reloading.patch

Deactivating SEND_MOVED code paths didn't help completely, thunar was still crashing on renaming sometimes (more often than not).

Alternative workaround. Does fix all? crashes on my system - I hope this isn't simply coincidence because of my lack of time for looking into this and testing -, but apparently some update problems remain when moving lots of files.

[Hjudt-l (hjudt-l)]

The update problems are also evident when a script renames multiple files at once. Maybe a rewrite for the changes in glib is still needed.

[Hjudt-l (hjudt-l)]

On a second thought, maybe these remaining update problems have existed in earlier versions too but simply went unnoticed. Anyway, here is a very simple test case to showcase the problem:

1) create files:
   for i in $(seq 1 10); do touch "$i.txt"; done
2) loop for renaming files every second:
   while true; do for i in $(seq 1 10); do mv "$i.txt" "$i.txt.txt"; done; sleep 1; for i in $(seq 1 10); do mv "$i.txt.txt" "$i.txt"; done; sleep 1; done

[Emil Mikulic (darkmoon)]

Copying from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800723#96:

This is with thunar-1.6.10: (line numbers will be off because I was
adding debug printfs)

thunar_file_info_reload() touches memory deleted by thunar_folder_reload()

I don't think this is a thread race because I always see both
functions running on the same thread.

What I think is happening here:

thunar_file_reload_idle() does:
 g_idle_add((GSourceFunc) thunar_file_reload, file);
This defers a call of thunar_file_reload(file) until after
thunar_folder_reload() has deleted "file"

The crash looks like this in valgrind:

==12276== Process terminating with default action of signal 11 (SIGSEGV)
==12276== Access not within mapped region at address 0x0
==12276== at 0x4362BA: thunar_file_info_reload (thunar-file.c:977)
==12276== by 0x436720: thunar_file_load.constprop.8 (thunar-file.c:1179)
==12276== by 0x4367BF: thunar_file_reload (thunar-file.c:3931)
==12276== by 0x7E37E89: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==12276== by 0x7E3822F: g_main_context_iterate.isra.29 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==12276== by 0x7E38551: g_main_loop_run (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==12276== by 0x5E0A586: gtk_main (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.29)
==12276== by 0x41FBF8: main (main.c:314)

glib's g_main_context_dispatch() is calling into thunar_file_reload(),
which means it came via g_idle_add.

Then we get to this part of thunar_file_info_reload():

    /* determine the basename */
    file->basename = g_file_get_basename (file->gfile); //[1]
    if (strcmp (file->basename, "kmsg") == 0 //[2]

[1] "file" has been freed, so the read (of gfile) and write (of
basename) are "invalid read/write of size 8" according to valgrind,
but don't crash.

g_file_get_basename() writes to the terminal:
(thunar:13169): GLib-GIO-CRITICAL **: g_file_get_basename: assertion
'G_IS_FILE (file)' failed

[2] file->basename is set to NULL, so the strcmp() attempt causes SIGSEGV.

(strcmp doesn't appear in the backtrace because it gets compiled to a
"repz cmpsb" instruction)

If I comment out the g_idle_add, the bad memory accesses seem to go away.

I'm not sure what the right fix for this is though.

[Emil Mikulic (darkmoon)]

With Check-if-a-thunar-file-is-still-valid-before-reloading.patch, I still see the invalid reads and writes, but not the crash on strcmp(NULL

Also, moving ~20 files (drag and drop to another thunar window) feels very slow now.

[Emil Mikulic (darkmoon)]

Sorry, to be clear: I still see the invalid reads and writes when I'm dragging and dropping files in the UI.

I tried the loop for renaming files every second and wasn't able to trigger a crash in thunar with or without the patch.

[Hjudt-l (hjudt-l)]

I believe the drag & drop issue you describe here has been there for a long time. I am not sure it has anything to do with this bug.

[Emil Mikulic (darkmoon)]

Oh, sorry, which bug should I be following up on?

[Hjudt-l (hjudt-l)]

No, it's ok, I just wanted to state that the issue *might* be a different one than the crashes. Does it also happen with cut & paste, not only drag&drop?

[Emil Mikulic (darkmoon)]

Yes, I'm pretty sure I've been able to trigger it with both copy/paste and drag/drop.

I don't have a reliable way of reproducing it, I manually click around until I get a crash.

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

[Gabriele-tozzi-c (gabriele-tozzi-c)]

I think I have more details to add: this bug happens always when the window is out of sync with the real filesystem state. By example, see #12452: when it happens, a subsequent rename will surely crash Thunar.
In general, it goes out-of-sync on network mounts quite often, so it should not be hard to reproduce.

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

[Emil Mikulic (darkmoon)]

Created attachment 6636
Use reference counting to avoid crash in deferred reload

I've got a semi-reliable way of triggering this (two side-by-side windows, showing two different dirs, a lot of image files, drag and drop and it crashes)

The attached diff increments the refcount before creating the deferred reload, then decrements it after the reload runs. I haven't been able to repro the crash since.

Could someone please take a look?

[Tony-paulic (tony-paulic)]

With the patch from comment #14 alone, crashing still happened on rename but infrequently (I found that if I Ctrl+c, Ctrl+v, F2, rename - that I could get it to crash every about 10th rename attempt, but infrequently through other methods).

With Emil's patch alone, crashing on rename happened much more frequently (every 3rd rename or so).

However, with both the patches applied, I have not seen a crash in about 100 renames. Will continue to test.

[Tony-paulic (tony-paulic)]

On Emil's prompting, I did some more testing today and found something interesting:

With Emil's patch only, the crashing only seems to happen if Thunar is running in daemon mode (I have "Thunar --daemon) in my startup list. Interestingly, if I run the Thunar instance through gdb and it crashes, there is no dump or backtrace (maybe because the Thunar daemon instance crashed?). If I run the Thunar daemon instance through gdb, it doesn't crash. I tried for a half hour and no crash. I then took it out of gdb, ran it manually, and on the first rename, it crashed.

So to recap:
- Emil's patch alone, thunar NOT in daemon mode = no crashing.
- Emil's patch alone, thunar in daemon mode = crashing (not as often today as every 3rd attempt though - more like every 20th).
- unable to get backtrace, as I can't seem to get Thunar in daemon mode to crash if running through gdb

[Arnaudv6 (arnaudv6)]

Was seeing a crash at each file move/renaming...
I have a pretty decent core i7 which might increase threads concurrency problems frequency...

Have ran thunar like so for quite some time and operations now without crash :
numactl --physcpubind=+1 thunar

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

[Ubuntu QA Website (ubuntuqa)]

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

[Pasi Lallinaho (knome)]

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

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

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

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

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 Sigmaring (stfidelis-deactivatedaccount)]

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

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

[Slumbergod-n (slumbergod-n)]

Still present in xubutu 16.04 LTS

[Martin-dauskardt (martin-dauskardt)]

The patch from Harald Judt in comment 30 of this thread resolves 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.

[pedra (petra-mueller29-deactivatedaccount)]

@ Martin Dauskardt: I cloned the current git repository and applied the patch from comment 30. Renaming a single file produced again a "SIGSEV in thunar_file_compare_by_name()" error after around the 20th attempt.

So this patch doesn't help at me at least. (On XUbuntu 16.04)

[Martin-dauskardt (martin-dauskardt)]

Are you really sure that new compiled thunar was running?
I suggest to remove the old /usr/bin/thunar and make a reboot

I did not use the git as base but patched the Ubuntu 15.10 source instead. You can find my compiled binary in the ubuntuusers forum. It should also work with Xubuntu 16.04

[Slumbergod-n (slumbergod-n)]

@ Martin Dauskardt
Are you using Xubuntu 16.04? Aren't you experiencing any of these crashes?

I don't understand why I am the only one seemingly affected. I did a clean install of xubuntu 16.04. No PPAs added. All xfce configuration were deleted with the clean install. Yet for me thunar crashes on almost every file copy or move.

I've even had the desktop crash when doing an archive extraction to a folder (the folder renamed itself after extraction and the desktop crashed).

I tried looking for your compiled binary to test but I cannot find it in the ubuntu users forum.

[Martin-dauskardt (martin-dauskardt)]

You are not the only one.
I use 15.10, but 16.04 is obviously also effected.
If you have the 64 bit version, you could try my binary. It also works on 16.04.
Have a look here: https://forum.ubuntuusers.de/post/8172653/
You need to rename the attachment, make it executable, change the owner to root and replace /usr/bin/thunar. A reboot is recommended.

While some users are regularly effected, others seem to have no problems. I read anywhere that it may depend on your view settings (detailed list view with showing of the file date?)

[Slumbergod-n (slumbergod-n)]

Thank you, Martin. I will explore changing my default view. I've always had it on detailed view so I'll be able to see the effect of that quickly.

If that fails I'll try the thunar file you directed me too.

I remember I tried 15.10 when it came out but there were so many issues with it I went back to 15.04 which was rock solid for me (older glib2 so thunar was very stable). But 15.04 doesn't get security updates any any more so I took a gamble that the thunar bugs in 16.04 LTS were resolved.

If I have any success with decreasing the crashes I'll post back so others can benefit too.

[Slumbergod-n (slumbergod-n)]

No success changing thunar default view to compact list. It crashed after a few file moves.

[Slumbergod-n (slumbergod-n)]

I don't want to proclaim the problem has gone, but I've been trying Martin's patched thunar binary and after dozens and dozens of attempts to trip it I have not yet managed to crash it yet. I'm using detailed view and dragging and dropping between two thunar windows, each pointing to directories on different drive partitions. Copying, Moving, and renaming with no crash yet.

I'll continue testing but what I can already say is that it MORE STABLE than the one that comes from the xubuntu 16.04 repos.

[Slumbergod-n (slumbergod-n)]

I now feel confident in saying that Martin's patched thunar binary is worth trying for anyone who has had enough of thunar crashing all the time.

I do not know why the "patched" version from the official 16.04 repositories is so unstable but I have not had a single crash in 24 hours with Martin's.

I'll add it as an attachment here with it's original name as found in the forum link provide by Martin (I hope you are OK with that, Martin).

If the replacement works for anyone else PLEASE post feedback here so it can help the developers.

Thanks, Martin!

[Slumbergod-n (slumbergod-n)]

Created attachment 6658
Martin's Patched Thunar Binary

[Ir2015-frms-g (ir2015-frms-g)]

Another positive testimonial for Martin's patch from me.

Not quite 24 hours of testing and more like half-an-hour of intensive renaming, copy-and-paste, drag-and-drop, all of which were previously causing Thunar to crash, now working flawlessly.

I'm running Xubuntu 16.04 (64-bit) - hope this helps!

[Martin-dauskardt (martin-dauskardt)]

Fine to hear that. Credit goes of course to Harald Judt who made the patch. I am only the compiler :-)

I discovered another patch in a BSD forum:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208341

Peter, maybe you can try this?

[Slackph (slackph)]

> I discovered another patch in a BSD forum:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208341

Hello Martin,

according to the links provided by Matthias Petermann, the mentioned patch is the one shared by Harald Judt in #30. In fact Matthias links to a related thread on Slackware's forum at LinuxQuestions.org, which I opened a few months ago after applying Harald's patch on my machine. I eventually marked it as solved, after the patch was applied by Slackware's maintainer Patrick Volkerding as well.

As you can see from the second link provided by Matthias, the patch included in Slackware's source repository is the one shared by Harald. As far as Slackware64-current is concerned this seems to work, as I haven't seen other complaints so far.

[Slackph (slackph)]

Sorry, I mentioned Harald's post #30 instead of #14.

[Slumbergod-n (slumbergod-n)]

Still no crashes for me. Curiously, I have detected one of the related bugs is still present though. I'll mention it here because I think it is related to the crashing bugs.

After dragging and dropping a file from one thunar window to another, sometimes to source window adds a ghost entry of the file just moved i.e. you move a file and it disappears from the source window then after a second it reappears, requiring a manual reload to remove the entry.

And while I remember, let me extend my thanks to Harald as well as Martin. I wish I could just use the official repo version of thunar but I am very grateful just to be able to use thunar again.

[Ubuntu QA Website (ubuntuqa)]

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

[Martin-dauskardt (martin-dauskardt)]

Created attachment 6660
64 bit binary with patches from comment 7,14,30,31,41 and master git patch from 30.11.15

With further testing using the example commands shown in #32 I recognize still crashes when using the patch from #30.

Same happens with Emils Patch in #41 (If used only or in combination with #30.)

The patch from Harald in #14 seems to be the most reliable solution, although he said himself that he still has crashes with it.

To be on the safe side, I now made a new binary which includes the following patches:

-'Fixing missing return value in standard view' from 30.11.2015 (already in master git)

-patches from comment Nr. 7, 14, 30, 31, 41 from this page.

Installation:
tar xvfz thunar.tgz -C /

[Slackph (slackph)]

I can confirm that Thunar patched as in #14 doesn't crash when running the test loop suggested by Harald in #32 (I tried it with 100 files as well).

[Slumbergod-n (slumbergod-n)]

Just an additional update on my experiences.

Thunar using Martin's binary (with the just Harald's patch). Not one crash.

I have managed to crash the desktop again, however. I downloaded the latest Firefox archive and extracted it to the desktop. When file-roller finished extracting and went to rename the directory as "firefox" the desktop crashed again. All the icons disappear and conky dies, then after a few seconds the icons return.

I'm guessing that the desktop relies on some of the same code as thunar so it is possibly to trigger a crash on renaming.

[Mikhail Kurinnoi (viewizard)]

(In reply to Emil Mikulic from comment #41)
> Could someone please take a look?

Work for me, thunar doesn't crash on drag and drop any more.

[John Lindgren (john-lindgren)]

Late to the party here. I have a feeling that there are multiple issues, and some of the patches may be addressing symptoms and not the root causes. One big issue that I see is in thunar-file.c, where there is one central hash table of ThunarFile objects, which are accessed concurrently from multiple threads with very inadequate protection against race conditions.

This patch fixes a bunch of g_object_ref warnings and an eventual crash for me:
https://github.com/jlindgren90/thunar/commit/9c6dbb1dae70

[B-frank-r (b-frank-r)]

After renaming a few files Thunar may crash after hitting enter in the rename dialog.

In an attempt to resolve this I used this patch:
-----------------------------------------------------------------------------
--- Thunar-1.6.10/thunar/thunar-file.c 2015-05-22 15:25:36.000000000 +0200
+++ Thunar-1.6.10-patched/thunar/thunar-file.c 2016-05-15 15:13:21.613406924 +0200
@@ -3918,7 +3918,9 @@
 gboolean
 thunar_file_reload (ThunarFile *file)
 {
- _thunar_return_if_fail (THUNAR_IS_FILE (file));
+ /* if the file has already been destroyed, break here */
+ if (!THUNAR_IS_FILE (file))
+ return FALSE;

  /* clear file pxmap cache */
  thunar_icon_factory_clear_pixmap_cache (file);
-----------------------------------------------------------------------------

It works but only if I click the OK button in the rename dialog. The crash occurs when hitting enter following the new name.

[B-frank-r (b-frank-r)]

(In reply to Frank from comment #66)
> After renaming a few files Thunar may crash after hitting enter in the
> rename dialog.
>
> In an attempt to resolve this I used this patch:
> -----------------------------------------------------------------------------
> --- Thunar-1.6.10/thunar/thunar-file.c 2015-05-22 15:25:36.000000000 +0200
> +++ Thunar-1.6.10-patched/thunar/thunar-file.c 2016-05-15
> 15:13:21.613406924 +0200
> @@ -3918,7 +3918,9 @@
> gboolean
> thunar_file_reload (ThunarFile *file)
> {
> - _thunar_return_if_fail (THUNAR_IS_FILE (file));
> + /* if the file has already been destroyed, break here */
> + if (!THUNAR_IS_FILE (file))
> + return FALSE;
>
> /* clear file pxmap cache */
> thunar_icon_factory_clear_pixmap_cache (file);
> -----------------------------------------------------------------------------
>
> It works but only if I click the OK button in the rename dialog. The crash
> occurs when hitting enter following the new name.

This patch is the same as referred to in comment #30.

[B-frank-r (b-frank-r)]

This bug definitely seems to be related to race conditions as has been suggested before.

You can do the test by hitting F2, entering an new name immediately followed by [ENTER]. Thunar is likely to crash. The same happens when you click OK too fast after entering a new name (put the mouse cursor on the button and press immediately after entering the last character).

When I leave a pause after entering a new name both the enter key and OK-button are much less likely to cause the crash (I have not experienced it yet).

[Cristian Vasile Mocanu (cvmocanu)]

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

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

[Jack Nihil (jnihil)]

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

[John Lindgren (john-lindgren)]

(In reply to Emil Mikulic from comment #41)
> The attached diff increments the refcount before creating the deferred
> reload, then decrements it after the reload runs. I haven't been able to
> repro the crash since.

I pushed a slightly simplified version of this patch to my fork:
https://github.com/jlindgren90/thunar/commit/e2d169d0c67d

Also fixes the drag-and-drop crash for me.

[Prahlad Yeri (prahladyeri)]

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

[Yanpas (yanpaso)]

Thunar crash has happened to me when I was moving file from one folder to another. I've dragged a file from file-list and dropped to the side panel's bookmark and thunar has crashed. I guess it's the same issue cause moving and renaming is almost the same thing

[Rocketx86 (rocketx86)]

After quite a bit of debugging and testing I have produced the following rename patch for Thunar.

--- Thunar-1.6.10/thunar/thunar-io-jobs.c 2015-05-22 13:25:36.000000000 +0000
+++ Thunar-1.6.10-fix/thunar/thunar-io-jobs.c 2016-08-01 11:07:09.016666668 +0000
@@ -1307,7 +1307,12 @@
 {
   _thunar_return_val_if_fail (THUNAR_IS_FILE (file), NULL);
   _thunar_return_val_if_fail (g_utf8_validate (display_name, -1, NULL), NULL);
-
+
+ if (!THUNAR_IS_FILE (file))
+ {
+ return NULL;
+ }
+
   return thunar_simple_job_launch (_thunar_io_jobs_rename, 2,
                                    THUNAR_TYPE_FILE, file,
                                    G_TYPE_STRING, display_name);

[Rocketx86 (rocketx86)]

(In reply to Roy Richardson from comment #71)

> After quite a bit of debugging and testing I have produced the following
> rename patch for Thunar.
>
> --- Thunar-1.6.10/thunar/thunar-io-jobs.c 2015-05-22 13:25:36.000000000 +0000
> +++ Thunar-1.6.10-fix/thunar/thunar-io-jobs.c 2016-08-01 11:07:09.016666668
> +0000

Unfortunately, further testing reveals that I am still able to crash Thunar.

[Slumbergod-n (slumbergod-n)]

@Roy, when you were testing did you also try to trigger a desktop crash?

Most times when I use Extract Here from the right click context menu on the desktop, it extracts the archive but when the temporary directory is renamed > DESKTOP CRASH! Did it yesterday when I extracted the latest firefox archive on the desktop (it gets renamed to just 'firefox' and that triggers it).

I think it is the same bug as the rename bug and if it is perhaps it is not thunar itself but the underlying libraries i.e. xfce4-desktop triggering the same crash as thunar.

Thoughts?

[Kip Warner (kip)]

(In reply to Roy Richardson from comment #72)
> Unfortunately, further testing reveals that I am still able to crash Thunar.

Man, this is quite elusive!

[Ketetefid (ketetefid)]

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

[Rocketx86 (rocketx86)]

@slumbergod I have never triggered an desktop crash, but I have seen a
numerous seg faults from various types of move or rename operations.

@Kip This bug is definately elusive and has traits of a stack corruption.

With debugging symbols enabled and NDEBUG defined to bypass the debugging
assertions, I was able to consistently catpure the following stack trace:

Thread 1 "thunar" received signal SIGSEGV, Segmentation fault.
0x00007ffff45ce60e in __strcmp_sse2_unaligned () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff45ce60e in __strcmp_sse2_unaligned () from /usr/lib/libc.so.6
#1 0x0000000000451102 in thunar_file_compare_by_name (file_a=0x7fffe0018ab0, file_b=0x7fffe001d040,
    case_sensitive=-1) at thunar-file.c:4024
#2 0x000000000046950a in thunar_list_model_cmp_func (a=0x7fffe0018ab0, b=0x7fffe001d040,
    user_data=0x830ea0) at thunar-list-model.c:1045
#3 0x00007ffff4b615d4 in ?? () from /usr/lib/libglib-2.0.so.0
#4 0x00007ffff4b61b1e in ?? () from /usr/lib/libglib-2.0.so.0
#5 0x00007ffff4b62934 in g_sequence_insert_sorted_iter () from /usr/lib/libglib-2.0.so.0
#6 0x00007ffff4b62a0c in g_sequence_insert_sorted () from /usr/lib/libglib-2.0.so.0
#7 0x000000000046a091 in thunar_list_model_files_added (folder=0x82f060, files=0x7fffffffdf00,
    store=0x830ea0) at thunar-list-model.c:1261
#8 0x00007ffff4e1dfa5 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#9 0x00007ffff4e2ffb2 in ?? () from /usr/lib/libgobject-2.0.so.0
#10 0x00007ffff4e38c1c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#11 0x00007ffff4e38fff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#12 0x00000000004535dd in thunar_folder_monitor (monitor=0xc865f0, event_file=0xc498c0,
    other_file=0xc49ae0, event_type=G_FILE_MONITOR_EVENT_MOVED, user_data=0x82f060)
    at thunar-folder.c:752
#13 0x00007fffeff701c8 in ffi_call_unix64 () from /usr/lib/libffi.so.6
#14 0x00007fffeff6fc2a in ffi_call () from /usr/lib/libffi.so.6
#15 0x00007ffff4e1ecba in g_cclosure_marshal_generic_va () from /usr/lib/libgobject-2.0.so.0
#16 0x00007ffff4e1e1d4 in ?? () from /usr/lib/libgobject-2.0.so.0
#17 0x00007ffff4e3890d in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#18 0x00007ffff4e38fff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#19 0x00007ffff515dc29 in ?? () from /usr/lib/libgio-2.0.so.0
#20 0x00007ffff4b48dd7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#21 0x00007ffff4b49040 in ?? () from /usr/lib/libglib-2.0.so.0
#22 0x00007ffff4b49362 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#23 0x00007ffff6a2a347 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#24 0x00000000004248b8 in main (argc=1, argv=0x7fffffffe868) at main.c:312

Eventually, I noticed the following:

In frame #12, a "file monitor move" signal is being handled. Subsequently,
In frame #7, a "files added" signal is being handled.

Should this be happening? No files are being created/added only moved.

I decided to see what would happen if "files added" wasn't signaled on a move.
The results are promising. I am no longer able to crash Thunar with a rename.
I have created the following patch to stop the "files added" on "move event"
behavi...

[Rocketx86 (rocketx86)]

(In reply to Jan Havran from comment #0)

> 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 patch will keep thunar_file_compare_by_name() from crashing when the collate keys are NULL. When using this patch, users may notice a random occurance of 2 files appearing selected together with the same name. The cause of this random occurance may be a result of the underlying issue after 'successful' sorting.

diff -Naurp Thunar-1.6.10/thunar/thunar-file.c Thunar-1.6.10-fix/thunar/thunar-file.c
--- Thunar-1.6.10/thunar/thunar-file.c 2015-05-22 13:25:36.000000000 +0000
+++ Thunar-1.6.10-fix/thunar/thunar-file.c 2016-08-04 17:41:14.330000001 +0000
@@ -4020,11 +4020,11 @@ thunar_file_compare_by_name (const Thuna

   /* case insensitive checking */
   if (G_LIKELY (!case_sensitive))
- result = strcmp (file_a->collate_key_nocase, file_b->collate_key_nocase);
+ result = g_strcmp0 (file_a->collate_key_nocase, file_b->collate_key_nocase);

   /* fall-back to case sensitive */
   if (result == 0)
- result = strcmp (file_a->collate_key, file_b->collate_key);
+ result = g_strcmp0 (file_a->collate_key, file_b->collate_key);

   /* this happens in the trash */
   if (result == 0)

[Kip Warner (kip)]

(In reply to Roy Richardson from comment #77)
> This patch will keep thunar_file_compare_by_name() from crashing when the
> collate keys are NULL. When using this patch, users may notice a random
> occurance of 2 files appearing selected together with the same name. The
> cause of this random occurance may be a result of the underlying issue after
> 'successful' sorting.

I've experienced that a couple of times now, so good to know where it started.

[Rocketx86 (rocketx86)]

(In reply to Roy Richardson from comment #76)

> I'm suspicious of the following code fragment in thunar_folder_monitor which
> I have now bypassed on "file monitor move" events with the above patch.
>
> /* tell others about the new file */
> list.data = file; list.next = list.prev = NULL;
> g_signal_emit (G_OBJECT (folder), folder_signals[FILES_ADDED], 0,
> &list);
>
> It is passing the address of a local GList variable to the "files added"
> signal handler. This needs further investigation as potential stack corruption.

The passing of the local GList variable by address to the "files added" signal handler does not seem to be causing any problems as far as I can see.

The problems seem to be caused when files are added to the list model multiple times by the file monitor after a move / rename operation. This seems to have somehow resulted in NULL collate keys which are causing the crash in strcmp().

The patch of thunar_folder_monitor to stop the "files added" on "move event" behavior is still working for me. I have not been able to crash Thunar with a rename or a move file since I have applied the patch. I am also not seeing the duplicate file anomoly that I see when just using the patch on thunar_file_compare_by_name().

[Main-haarp (main-haarp)]

At this point it almost seems less work to strip everything remotely related to renaming and rewrite it.

[Yanpas (yanpaso)]

You may write stack trace to the file on SIGSEGV https://stackoverflow.com/questions/77005/how-to-generate-a-stacktrace-when-my-gcc-c-app-crashes

and then via objdump -d find line in assembler where app gets sigsegv (I guess it crashes due to sigsegv)

[Rocketx86 (rocketx86)]

Created attachment 6767
Patch to thunar_folder_monitor to stop "files added" on "monitor move" event

The attached patch updates the code in thunar_folder_monitor with a fix to prevent the rename crashes by stopping the "files added" on "monitor move" event behaviour. I can no longer reproduce any move or rename crash with this patch. I have successfully tested the this on both Arch.x86_64 and Debian.i386. Please review and test as much as possible so we can get this bug closed.

[Slumbergod-n (slumbergod-n)]

If anyone compiles a thunar binary compatible with xubuntu 16.04 I am happy to test it.

I'd be happy to compile it myself but the last time I tried I made a mess of my system because the instructions I found for compiling it weren't accurate enough.

But I am happy to help test binaries :)

[Cleanrock (cleanrock)]

(In reply to Roy Richardson from comment #82)
> Created attachment 6767 [details]
> Patch to thunar_folder_monitor to stop "files added" on "monitor move" event
I patched archlinux thunar (thunar 1.6.10-3, x86_64) with this patch and I am unable to reproduce the crash.

[Slumbergod-n (slumbergod-n)]

With some help I was able to compile thunar with the new patch for xubuntu 16.04

Curiously, I wasn't able to trigger a crash running the renaming test but it just crashed during a renaming session using thunar's batch renaming tool.

Has anyone else had a crash with the patch?

[Slumbergod-n (slumbergod-n)]

And crashing with dragging and dropping has returned for me. I will roll back to the previous patched version I was using.

[B-frank-r (b-frank-r)]

I can confirm the crash with drag-drop operations after applying th patch from comment #76. I opened two instances of Thunar, selected two different folders and moved a file from one location to the next using drag-drop. This went ok. However, when moving the file back Thunar crashed. It turned out that the file was moved back before the crash though.

[Slumbergod-n (slumbergod-n)]

Harald's patch solves the drag/drop crashes.
Roy's patch solves the renaming crashes.

I guess we need to combine them both. Perhaps someone with more programming experience can tell us if the two patches are likely to interfere with one another.

[Yanpas (yanpaso)]

As I commented earlier you may find where you program crashes, just add SIGSEGV handler and export stack trace somewhere. I'm sure that there is segfault, not stack overflow or call of exit function.

[John Lindgren (john-lindgren)]

At one point, it seemed that the two patches from comment #14 (Harald) and comment #41 (Emil) were enough to fix two separate crashes: one triggered by rename, one triggered by drag-and-drop.

Harald himself stated that his patch was not intended as a real fix, just a workaround. I wrote an alternate fix[1] and pushed it, along with Emil's patch, to my GitHub fork[2].

Since then, there have been several further reports of crashes, and some new patches posted. Can those who are still experiencing crashes please confirm whether you have the fixes from my fork applied?

[1] https://github.com/jlindgren90/thunar/commit/9c6dbb1dae70
[2] https://github.com/jlindgren90/thunar

[Yuri Ribeiro Sucupira (yuri-sucupira)]

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

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

[Pomidorabelisima (pomidorabelisima)]

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

[Benji (benjim)]

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

[Rocketx86 (rocketx86)]

(In reply to John Lindgren from comment #90)

> At one point, it seemed that the two patches from comment #14 (Harald) and
> comment #41 (Emil) were enough to fix two separate crashes: one triggered by
> rename, one triggered by drag-and-drop.
>
> Harald himself stated that his patch was not intended as a real fix, just a
> workaround. I wrote an alternate fix[1] and pushed it, along with Emil's
> patch, to my GitHub fork[2].
>
> Since then, there have been several further reports of crashes, and some new
> patches posted. Can those who are still experiencing crashes please confirm
> whether you have the fixes from my fork applied?
>
> [1] https://github.com/jlindgren90/thunar/commit/9c6dbb1dae70
> [2] https://github.com/jlindgren90/thunar

It is certainly much more difficult to crash Thunar 1.6.10 with these 3 patches applied.

1. #14 Harald's deactivate SEND_MOVED code paths
2. #41 Emil's reference counting to avoid crash in deferred reload
3. #65 John's don't call g_object_ref/unref on objects that are being finalized

Unfortunately, while running a release build with these 3 patches, Thunar will still crash on rename and output the following messages:

(thunar:12326): GLib-GObject-WARNING **: instance of invalid non-instantiatable type '(null)'

(thunar:12326): GLib-GObject-CRITICAL **: g_signal_handlers_destroy: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
Segmentation fault (core dumped)

While running a debug build inside GDB, I was able to capture the following stack trace which seems to correspond to the instance check failure and resulting segmentation fault.

(thunar:27537): GLib-GObject-WARNING **: instance of invalid non-instantiatable type '(null)'

Thread 71 "pool" received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0x7fffe9301700 (LWP 28891)]
0x00007ffff4b5070b in g_logv () from /usr/lib/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff4b5070b in g_logv () from /usr/lib/libglib-2.0.so.0
#1 0x00007ffff4b5087f in g_log () from /usr/lib/libglib-2.0.so.0
#2 0x00007ffff4e43e85 in g_type_check_instance () from /usr/lib/libgobject-2.0.so.0
#3 0x00007ffff4e37c96 in g_signal_handlers_destroy () from /usr/lib/libgobject-2.0.so.0
#4 0x00007ffff4e23c7a in g_object_unref () from /usr/lib/libgobject-2.0.so.0
#5 0x000000000043d862 in thunar_file_info_clear (file=0x7fffe00203b0) at thunar-file.c:912
#6 0x000000000043df96 in thunar_file_load (file=0x7fffe00203b0, cancellable=0x0, error=0x0) at thunar-file.c:1184
#7 0x000000000043d41e in thunar_file_monitor_moved (file=0x7fffe00203b0, renamed_file=0xc3d380) at thunar-file.c:733
#8 0x000000000043f02f in thunar_file_rename (file=0x7fffe00203b0, name=0xb31e00 "15.txt", cancellable=0xb62080,
    called_from_job=1, error=0x7fffe9300bb8) at thunar-file.c:1956
#9 0x000000000044c39a in _thunar_io_jobs_rename (job=0xb08cb0, param_values=0xa95f20, error=0x7fffe9300c10)
    at thunar-io-jobs.c:1285
#10 0x000000000047eb4c in thunar_simple_job_execute (job=0xb08cb0, error=0x7fffe9300c40) at thunar-simple-job.c:119
#11 0x00007ffff79b0977 in ?? () from /usr/lib/libexo-1.so.0
#12 0x00007ffff50c3276 in ?? () from /usr/lib/libgio-2.0.so.0
#13 0x00007ffff50e924d in ?? () from /...

[John Lindgren (john-lindgren)]

(In reply to Roy Richardson from comment #92)
> #4 0x00007ffff4e23c7a in g_object_unref () from /usr/lib/libgobject-2.0.so.0
> #5 0x000000000043d862 in thunar_file_info_clear (file=0x7fffe00203b0) at
> thunar-file.c:912

This is most likely due to multiple threads clobbering the GFileInfo within the same ThunarFile. At this point, I guess I would say that the basic design of sharing the common hash table of ThunarFiles between multiple threads is flawed. Worker threads ought to be using their own local copies until they're finished, and then send the data back to the main thread in a orderly fashion (probably making use of g_idle_add). I implemented something of the sort when I rewrote the playlist code of Audacious a few years ago.

Perhaps haarp is right (comment #80), the code just needs to be rewritten.

[Slumbergod-n (slumbergod-n)]

Perhaps it is time to fund a dedicated, professional software engineer to fix this once and for all. It's clear that parts of the code base need a complete rewrite and at the moment it feels like the patches are only mitigating the symptoms rather than addressing the real cause.

Maybe this is something that can be crowdfunded. Please *don't* flame me for making this suggestion but as someone who loves xfce and thunar I'd be happy to contribute money towards such a goal and so would many others who are tired of thunar crashing.

It's just a suggestion. It just seems we are not really making progress carrying on the way we are.

[Xfce-d (xfce-d)]

slumbergod is right: The bug has not been tracked down, yet. By now it seems pretty clear that the bug is caused by different threads that operate on the same data(structures). Unfortunately bugs, which are related to multithreading are hard to track down, since they are non-deterministic and different parts of the code, which are executed concurrently, may need to be adapted.

However, it seems that nobody really understands the code, but just fiddles around with it, in hope the bug will magically disappear. If debugging is done this way, it is much more likely that the opposite effect will occur: New bugs are introduced.

Roy for example proposed in comment #71 to add an additional check to the code:
> if (!THUNAR_IS_FILE (file))
> {
> return NULL;
> }

This additional check may reduce the number of crashes, but it does not cure the cause (As Roy discovered in comment #72): If the OS triggers a thread switch between the check and the execution of the following operations, the result of the check may no longer hold.

I guess, that some type of synchronization will be needed to patch the bug. Therefore is it necessary to identify the critical sections and implement mutual exclusion.

PS: Sorry, if this post sounds a bit harsh. I do not want to offend anyone - especially not Roy - but just want to point further efforts into the right direction.

[Rocketx86 (rocketx86)]

(In reply to John Lindgren from comment #93)

> This is most likely due to multiple threads clobbering the GFileInfo within
> the same ThunarFile. At this point, I guess I would say that the basic
> design of sharing the common hash table of ThunarFiles between multiple
> threads is flawed. Worker threads ought to be using their own local copies
> until they're finished, and then send the data back to the main thread in a
> orderly fashion (probably making use of g_idle_add). I implemented
> something of the sort when I rewrote the playlist code of Audacious a few
> years ago.
>
> Perhaps haarp is right (comment #80), the code just needs to be rewritten.

Perhaps, but in the meantime, many people could use a temporary patch, including myself.

Using only Harald's 'deactivate SEND_MOVE code paths' patch on 1.6.10, I've been able to capture another stack trace that indicates multiple threads clearing and reloading the GFileInfo within the same ThunarFile.

(thunar:23134): GLib-CRITICAL **: g_utf8_casefold: assertion 'str != NULL' failed

#2 0x00007ffff4b7854c in g_utf8_casefold () from /usr/lib/libglib-2.0.so.0
#3 0x000000000043dd3d in thunar_file_info_reload (file=0x7fffe001d5a0, cancellable=0x0) at thunar-file.c:1079
#4 0x000000000043dfdc in thunar_file_load (file=0x7fffe001d5a0, cancellable=0x0, error=0x0) at thunar-file.c:1193

I'm testing additional synchronization around critical sections containg calls to thunar_file_info_clear() and thunar_file_info_reload() in the following functions:

thunar_file_load()
thunar_file_get_with_info()
thunar_file_get_async_finish()

[Yuri Ribeiro Sucupira (yuri-sucupira)]

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

[Xbarbie-4 (xbarbie-4)]

Firstly, I apologise for being such newbie in these things, if this post does not belong here, please ignore it. I am experiencing this same bug as many people reported, This looks like the best solution I have found. As I do not know where to ask, I ask here:

Is there any guide / list of detailed steps, or even some automatic script to use for building the patched version of thunar that I could build?

(I have never do such thing as compiling program from source, do not how to "apply a patch" - as I said I'm a total newbie. But maybe such guide will help the other users to solve the problem until it will be solved the "official" way.)

Once again, sorry, this is maybe off-topic, because you all are programmers and experts. Thank you for your time and bye.

[Pomidorabelisima (pomidorabelisima)]

(In reply to slumbergod from comment #94)
> Perhaps it is time to fund a dedicated, professional software engineer to
> fix this once and for all. It's clear that parts of the code base need a
> complete rewrite and at the moment it feels like the patches are only
> mitigating the symptoms rather than addressing the real cause.
>
> Maybe this is something that can be crowdfunded. [...]

https://www.bountysource.com/issues/27554063-crash-when-renaming-single-file-in-folder

[Slumbergod-n (slumbergod-n)]

Offering a bounty is a nice idea but I still think this requires something bigger. We really need to crowdfund to hire a software engineer to re-write a significant chunk of code rather than just work out a single fix.

It might even lead to some of the other papercut bugs getting sorted (I know I've posted bug reports for several small "weird" behaviours that shouldn't be considered "normal" behaviour in a file manager.

Too bad thunar is written in C. If it was Python or something higher level we'd probably have these things sorted because more people would be able to contribute (myself included).

[Main-haarp (main-haarp)]

(In reply to slumbergod from comment #99)
> Offering a bounty is a nice idea but I still think this requires something
> bigger. We really need to crowdfund to hire a software engineer to re-write
> a significant chunk of code rather than just work out a single fix.
>
> It might even lead to some of the other papercut bugs getting sorted (I know
> I've posted bug reports for several small "weird" behaviours that shouldn't
> be considered "normal" behaviour in a file manager.
>
> Too bad thunar is written in C. If it was Python or something higher level
> we'd probably have these things sorted because more people would be able to
> contribute (myself included).

If a significant portion of it needs to be rewritten anyway, maybe it could be worth considering porting it to another language entirely. I agree that Python would be an excellent candidate.

It would make development much easier and as you said, take care of the many papercuts that Thunar does indeed currently have. Plus, Thunar needs to be ported to GTK3 eventually anyway.

I like C, but writing GUI applications in it is a nightmare.

[Slumbergod-n (slumbergod-n)]

Nothing can proceed forwards until we get some feedback from the main xfce developers.

I'm not even sure if anyone is in charge of the thunar project and my attempts in the past to ask what the status of the project is with regard to fixing the bugs have gone unanswered.

Perhaps they have a plan in action already (other than just applying patches to address the symptoms)? It would be nice to know "yes, we have it sorted" or "no, we have no clue".

[Main-haarp (main-haarp)]

(In reply to slumbergod from comment #101)
> Nothing can proceed forwards until we get some feedback from the main xfce
> developers.
>
> I'm not even sure if anyone is in charge of the thunar project and my
> attempts in the past to ask what the status of the project is with regard to
> fixing the bugs have gone unanswered.
>
> Perhaps they have a plan in action already (other than just applying patches
> to address the symptoms)? It would be nice to know "yes, we have it sorted"
> or "no, we have no clue".

Harald Judt is in charge of Thunar, but he appears to not have much spare time at the moment. I highly doubt anyone is working on porting Thunar to GTK3 at the moment, nor could I find anything about it in the mailing list (it would be wise to ask around tho).

My impression is that many Xfce components are severely lacking manpower.

Hence my suggestion. Porting to Python would kill multiple birds with one stone:

- Port to GTK3
- Fix this crash
- Fix other bugs
- Easier to use language
- Pull in more developers

I think this is getting off-topic tho. Should we move this to the mailing list?

[Slumbergod-n (slumbergod-n)]

Yes, please add it to the mailing list and ask for Harald's thoughts.

I'm not on any mailing lists because I got tired of the egos and flaming.

Perhaps if Harald gives his thoughts and something is decided you can just post a small summary here for the benefit of those affected who simply want to know something constructive is being planned / actioned.

Thank you :)

[Htd-c (htd-c)]

Well, Thunar is dead. Period. There are a bunch of other replacements like xfe, nautilus, whatever that just work. There is obviously sparse interest, if any, in developing thunar. And hey, that's ok, after all it is free software and times are changing.

So let us all recognize that and move on, to something more useful. I already did.

[Flo-xfce (flo-xfce)]

Please stop the discussion about rewriting Thunar, Bountyhunting, switching to different file managers, etc. - it has nothing to do with the bug report and only adds clutter which makes it even harder to track progress.
The mailing list is a good alternative, or start a new bug report for each mentioned issue.

[Slumbergod-n (slumbergod-n)]

You could have been friendlier. Instead you show yourself to be an asshole. Adios.

[J-g-rennison+xfce4-bugzilla (j-g-rennison+xfce4-bugzilla)]

Created attachment 6778
This changes tunar_file_rename/_thunar_io_jobs_rename so that thunar_file_monitor_moved is called in the main thread, instead of the IO job thread.

[J-g-rennison+xfce4-bugzilla (j-g-rennison+xfce4-bugzilla)]

The patch in attachment 6778 above moves the call to thunar_file_monitor_moved which was previously done within thunar_file_rename when called by _thunar_io_jobs_rename in an IO thread job, to be instead called by a new function thunar_file_rename_notify by _thunar_io_jobs_rename_notify in the main thread.
This is as thunar_file_monitor_moved does various things which are not safe to do outside of the main thread.

I've been using this patch above in combination with the send move path deactivating patch in attachment 6530 for about six months now, and it seems to have resolved the rename crashing issues for me.

[Rocketx86 (rocketx86)]

Created attachment 6779
Handle folder change events with file info synchronization

Here's the latest set of changes that I have been testing which handle folder change events and synchronize updates to file info by multiple threads.

The patch contains the following changes to address the problems:

1. The file monitor no longer watches for move / rename events. (Harald's patch)
thunar_file_monitor no longer handles G_FILE_MONITOR_EVENT_MOVED.
thunar_file_monitor_moved has been renamed to thunar_file_renamed which is only called by thunar_file_rename.

2. The folder monitor now watches for move events using the newer G_FILE_MONITOR_WATCH_MOVES flag.
thunar_file_monitor no longer handles G_FILE_MONITOR_EVENT_MOVED.
thunar_file_monitor now handles G_FILE_MONITOR_EVENT_CREATED, G_FILE_MONITOR_EVENT_MOVED_IN, G_FILE_MONITOR_EVENT_DELETED, G_FILE_MONITOR_EVENT_MOVED_OUT and G_FILE_MONITOR_EVENT_RENAMED events.

3. Added thread synchronization around critical sections clearing and reloading file info by introducing locking on file_info_mutex in thunar_file_get_async_finish, thunar_file_load and thunar_file_get_with_info.

[Pomidorabelisima (pomidorabelisima)]

(In reply to Jonathan Rennison from comment #108)
> The patch in attachment 6778 [details] above moves the call to
> thunar_file_monitor_moved which was previously done within
> thunar_file_rename when called by _thunar_io_jobs_rename in an IO thread
> job, to be instead called by a new function thunar_file_rename_notify by
> _thunar_io_jobs_rename_notify in the main thread.
> This is as thunar_file_monitor_moved does various things which are not safe
> to do outside of the main thread.
>
> I've been using this patch above in combination with the send move path
> deactivating patch in attachment 6530 [details] for about six months now,
> and it seems to have resolved the rename crashing issues for me.

Those two patches moreover fix SEGV on move files,
threrefore +1

p.s.
After this is applied,
how about
merge https://github.com/rgcjonas/thunar-gtk3
to https://git.xfce.org

Ref.
https://mail.xfce.org/pipermail/xfce4-dev/2015-August/031440.html
Jonas Kümmerlin

https://bugzilla.xfce.org/show_bug.cgi?id=12772#c10

[Derk Willem te Bokkel (dtebokkel)]

patch in attachment 6779 will not apply .. seems damaged?? incomplete lines?

patch does not " find the file to patch .. incorrect -p or strip option .."

the other patches 6778 and 6530 apply fine but I still had a crash on a file move

for thunar-gtk3 with patches..

[Derk Willem te Bokkel (dtebokkel)]

ok manually edited files to match patch-attachment 6779 .. discovered another chunk of code (an if statement not in the source that 6779 was patched against) removed the extra if and the patched source compiled and built fine .. but crashed attempting the first file move ..

this is just 6779 w/o the 6778 and 6630 patches as they appear to conflict with 6779 ..

[WebDawg (webdawg)]

Thread 1 "thunar" received signal SIGSEGV, Segmentation fault.
0x00007ffff466fd26 in __strcmp_ssse3 () from /usr/lib/libc.so.6

(gdb) bt
#0 0x00007ffff466fd26 in __strcmp_ssse3 () from /usr/lib/libc.so.6
#1 0x00000000004340ad in ?? ()
#2 0x00000000004406cb in ?? ()
#3 0x00007ffff4b645d4 in ?? () from /usr/lib/libglib-2.0.so.0
#4 0x00007ffff4b64b1e in ?? () from /usr/lib/libglib-2.0.so.0
#5 0x00007ffff4b65934 in g_sequence_insert_sorted_iter () from /usr/lib/libglib-2.0.so.0
#6 0x00007ffff4b65a0c in g_sequence_insert_sorted () from /usr/lib/libglib-2.0.so.0
#7 0x00000000004405fa in ?? ()
#8 0x00007ffff4e20fa5 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#9 0x00007ffff4e32fb2 in ?? () from /usr/lib/libgobject-2.0.so.0
#10 0x00007ffff4e3bc1c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#11 0x00007ffff4e3bfff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#12 0x0000000000435547 in ?? ()
#13 0x00007fffeffa01c8 in ffi_call_unix64 () from /usr/lib/libffi.so.6
#14 0x00007fffeff9fc2a in ffi_call () from /usr/lib/libffi.so.6
#15 0x00007ffff4e21cba in g_cclosure_marshal_generic_va () from /usr/lib/libgobject-2.0.so.0
#16 0x00007ffff4e211d4 in ?? () from /usr/lib/libgobject-2.0.so.0
#17 0x00007ffff4e3b90d in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#18 0x00007ffff4e3bfff in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#19 0x00007ffff5160c29 in ?? () from /usr/lib/libgio-2.0.so.0
#20 0x00007ffff4b4bdd7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#21 0x00007ffff4b4c040 in ?? () from /usr/lib/libglib-2.0.so.0
#22 0x00007ffff4b4c362 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#23 0x00007ffff6a2d347 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#24 0x000000000041ed11 in ?? ()
#25 0x00007ffff45672d1 in __libc_start_main () from /usr/lib/libc.so.6
#26 0x000000000041ee49 in ?? ()

When I rename Car_Ins_Documents_Signed.pdf to 2016.08.26-Car_Ins_Documents_Signed.pdf

Let me know what I need to do if anything to help on this. I can pretty much make it crash all the time if I want on two different up to date archlinux boxes. It happens more and more and has been happening for about a year.

[Rocketx86 (rocketx86)]

Created attachment 6801
Notes for patching Thunar on Ubuntu with patch #6779

I've successfully tested patch #6779 on Debian Stretch i386, Debian Stretch amd64, Xubuntu 16.04 amd64 and Arch x86_64. Here are my notes for patching and building Thunar on Ubuntu. I hope this works as well for you as it does for me.

[Xbarbie-4 (xbarbie-4)]

(In reply to Roy Richardson from comment #114)
> Created attachment 6801 [details]
> Notes for patching Thunar on Ubuntu with patch #6779
>
>
> I've successfully tested patch #6779 on Debian Stretch i386, Debian Stretch
> amd64, Xubuntu 16.04 amd64 and Arch x86_64. Here are my notes for patching
> and building Thunar on Ubuntu. I hope this works as well for you as it does
> for me.

This looks great, is there a way that you could provide the patched .deb file? I am afraid of doing that compiling thing, as I never did it. I am running Xubuntu 16.04 amd64 too so I think it will be working ok, is that true?
Thanks.
xb.

[Robert M. Muncrief (rmuncrief-9)]

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

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?

[Yuri Ribeiro Sucupira (yuri-sucupira)]

(In reply to xb from comment #115)
> (In reply to Roy Richardson from comment #114)
> > Created attachment 6801 [details]
> > Notes for patching Thunar on Ubuntu with patch #6779
> >
> >
> > I've successfully tested patch #6779 on Debian Stretch i386, Debian Stretch
> > amd64, Xubuntu 16.04 amd64 and Arch x86_64. Here are my notes for patching
> > and building Thunar on Ubuntu. I hope this works as well for you as it does
> > for me.
>
> This looks great, is there a way that you could provide the patched .deb
> file? I am afraid of doing that compiling thing, as I never did it. I am
> running Xubuntu 16.04 amd64 too so I think it will be working ok, is that
> true?
> Thanks.
> xb.

I've managed to build and install the (actually five) "patched" DEB packages. Now Thunar seems to be back to normal, although I still have more testing to do.

I've uploaded those packages to my OneDrive:

https://1drv.ms/f/s!AvGdllDm3m3njxZrQkEimLKwSsEI

They're for 64-bit systems, only.

For installation instructions and other info, please read the README.txt file that I've uploaded to that same folder.

[Kip Warner (kip)]

(In reply to Yuri R. Sucupira from comment #116)
> I've managed to build and install the (actually five) "patched" DEB
> packages. Now Thunar seems to be back to normal, although I still have more
> testing to do.
>
> I've uploaded those packages to my OneDrive:
>
> https://1drv.ms/f/s!AvGdllDm3m3njxZrQkEimLKwSsEI
>
> They're for 64-bit systems, only.
>
> For installation instructions and other info, please read the README.txt
> file that I've uploaded to that same folder.

Hey Yuri. Thanks a lot. It might be better though if you consider pushing to a PPA. That's a more "standard" method of distributing personal / testing debs.

[Xbarbie-4 (xbarbie-4)]

(In reply to Yuri R. Sucupira from comment #116)
> (In reply to xb from comment #115)
> > (In reply to Roy Richardson from comment #114)
> > > Created attachment 6801 [details]
> > > Notes for patching Thunar on Ubuntu with patch #6779
> > >
> > >
> > > I've successfully tested patch #6779 on Debian Stretch i386, Debian Stretch
> > > amd64, Xubuntu 16.04 amd64 and Arch x86_64. Here are my notes for patching
> > > and building Thunar on Ubuntu. I hope this works as well for you as it does
> > > for me.
> >
> > This looks great, is there a way that you could provide the patched .deb
> > file? I am afraid of doing that compiling thing, as I never did it. I am
> > running Xubuntu 16.04 amd64 too so I think it will be working ok, is that
> > true?
> > Thanks.
> > xb.
>
> I've managed to build and install the (actually five) "patched" DEB
> packages. Now Thunar seems to be back to normal, although I still have more
> testing to do.
>
> I've uploaded those packages to my OneDrive:
>
> https://1drv.ms/f/s!AvGdllDm3m3njxZrQkEimLKwSsEI
>
> They're for 64-bit systems, only.
>
> For installation instructions and other info, please read the README.txt
> file that I've uploaded to that same folder.

Thank you, Yuri, I will try it, hope it will work on my machine.
xb

[Yuri Ribeiro Sucupira (yuri-sucupira)]

(In reply to xb from comment #118)
> (In reply to Yuri R. Sucupira from comment #116)
> > (In reply to xb from comment #115)
> > > (In reply to Roy Richardson from comment #114)
> > > > Created attachment 6801 [details]
> > > > Notes for patching Thunar on Ubuntu with patch #6779
> > > >
> > > >
> > > > I've successfully tested patch #6779 on Debian Stretch i386, Debian Stretch
> > > > amd64, Xubuntu 16.04 amd64 and Arch x86_64. Here are my notes for patching
> > > > and building Thunar on Ubuntu. I hope this works as well for you as it does
> > > > for me.
> > >
> > > This looks great, is there a way that you could provide the patched .deb
> > > file? I am afraid of doing that compiling thing, as I never did it. I am
> > > running Xubuntu 16.04 amd64 too so I think it will be working ok, is that
> > > true?
> > > Thanks.
> > > xb.
> >
> > I've managed to build and install the (actually five) "patched" DEB
> > packages. Now Thunar seems to be back to normal, although I still have more
> > testing to do.
> >
> > I've uploaded those packages to my OneDrive:
> >
> > https://1drv.ms/f/s!AvGdllDm3m3njxZrQkEimLKwSsEI
> >
> > They're for 64-bit systems, only.
> >
> > For installation instructions and other info, please read the README.txt
> > file that I've uploaded to that same folder.
>
> Thank you, Yuri, I will try it, hope it will work on my machine.
> xb

You're welcome.

After I executed `sudo apt-get dist-upgrade`, APT replaced the patched version by the buggy repo version. Thus, I had to manually reinstall the patched packages.

In order to prevent it from happening again, I held the 5 packages, which is done by running this command:

sudo apt-mark hold thunar thunar-dbg thunar-data libthunarx-2-0 libthunarx-2-dev

This will prevent APT from replacing those packages during an `upgrade` or `dist-upgrade`.

When a new Thunar release becomes available, all the user has to do is to run this command:

sudo apt-mark unhold thunar thunar-dbg thunar-data libthunarx-2-0 libthunarx-2-dev

...and then run `sudo apt-get upgrade` or `sudo apt-get dist-upgrade` to cause APT to install the new Thunar release.

I've updated the README.txt file on my OneDrive. Now it explains how to hold/unhold DEB packages.

[Yuri Ribeiro Sucupira (yuri-sucupira)]

(In reply to Kip from comment #117)
> (In reply to Yuri R. Sucupira from comment #116)
> > I've managed to build and install the (actually five) "patched" DEB
> > packages. Now Thunar seems to be back to normal, although I still have more
> > testing to do.
> >
> > I've uploaded those packages to my OneDrive:
> >
> > https://1drv.ms/f/s!AvGdllDm3m3njxZrQkEimLKwSsEI
> >
> > They're for 64-bit systems, only.
> >
> > For installation instructions and other info, please read the README.txt
> > file that I've uploaded to that same folder.
>
> Hey Yuri. Thanks a lot. It might be better though if you consider pushing to
> a PPA. That's a more "standard" method of distributing personal / testing
> debs.

I created a PPA and tried to upload data to it, but the process proved to be a real pain in the *ss. After a very long run (because I never had to do it before in my life), I finnaly managed to create a local key on my system, upload this key to the Ubuntu keyserver, confirm my id to the keyserver, and then sign the Code of Conduct. However, those were just the preliminary steps required to allow me to create a PPA and push files into it. And unfortunately I didn't succeed in uploading data to the PPA (I'm using dput, but something's going wrong). I thought I could push the DEB files to the PPA, but it's actually forbidden: one must push the sources, which I'm failing to do, maybe because I'm failing to find out how to sign the source-code and how to authenticate into the PPA in order to push the files into it. I'll try again later, but I'm under the impression that I won't succeed.

My key expires in Sep. 02, 2017, so if I happen to succeed in uploading these patched files to a PPA it will stay "active" for 1 year, which I assume is more than enough time for a new Thunar release come up with this bug fixed. Anyway, I still don't know how to push these files to a PPA. I'll let you all know if I overcome this problem.

In the meantime, I suggest downloading the DEBs from my OneDrive. Unfortunately it's the only cloud hosting method I currently know how to do. :-\

[Kip Warner (kip)]

(In reply to Yuri R. Sucupira from comment #120)
> And
> unfortunately I didn't succeed in uploading data to the PPA (I'm using dput,
> but something's going wrong). I thought I could push the DEB files to the
> PPA, but it's actually forbidden: one must push the sources, which I'm
> failing to do, maybe because I'm failing to find out how to sign the
> source-code and how to authenticate into the PPA in order to push the files
> into it. I'll try again later, but I'm under the impression that I won't
> succeed.

Hey Yuri,

Yes, working with a PPA (sbuild) can be a real pain. I've learned over the years how to do it. All of the things you raised are definitely annoying, but there's actually very good reasons for all of them that make packages better. This is the reason why Debian has such a very high quality selection of packages because of their high standards. I really recommend checking out the Debian Policy Manual at some point for future benefit too.

[Yuri Ribeiro Sucupira (yuri-sucupira)]

(In reply to Roy Richardson from comment #114)
> Created attachment 6801 [details]
> Notes for patching Thunar on Ubuntu with patch #6779
>
>
> I've successfully tested patch #6779 on Debian Stretch i386, Debian Stretch
> amd64, Xubuntu 16.04 amd64 and Arch x86_64. Here are my notes for patching
> and building Thunar on Ubuntu. I hope this works as well for you as it does
> for me.

@Roy: thank you very much for the notes on patching and building Thunar on Ubuntu! It's been 4 days since I've built and installed the patched binaries and so far Thunar hasn't had any crash related to file moving/renaming.

[Yuri Ribeiro Sucupira (yuri-sucupira)]

(In reply to Kip from comment #121)
> (In reply to Yuri R. Sucupira from comment #120)
> > And
> > unfortunately I didn't succeed in uploading data to the PPA (I'm using dput,
> > but something's going wrong). I thought I could push the DEB files to the
> > PPA, but it's actually forbidden: one must push the sources, which I'm
> > failing to do, maybe because I'm failing to find out how to sign the
> > source-code and how to authenticate into the PPA in order to push the files
> > into it. I'll try again later, but I'm under the impression that I won't
> > succeed.
>
> Hey Yuri,
>
> Yes, working with a PPA (sbuild) can be a real pain. I've learned over the
> years how to do it. All of the things you raised are definitely annoying,
> but there's actually very good reasons for all of them that make packages
> better. This is the reason why Debian has such a very high quality selection
> of packages because of their high standards. I really recommend checking out
> the Debian Policy Manual at some point for future benefit too.

After a LOT of pain (it took me some hours) I finally managed to sign my sources and upload'em to a PPA. Here's the PPA:

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

However, I noticed that APT is considering "1.6.10-2ubuntu1" as a newer version than my "1.6.10-2ubuntu1~patch1" version. Does anyone know how I shall version my packages, in order to make APT choose them instead of those in version 1.6.10-2ubuntu1?

[Kip Warner (kip)]

(In reply to Yuri R. Sucupira from comment #123)
> After a LOT of pain (it took me some hours) I finally managed to sign my
> sources and upload'em to a PPA. Here's the PPA:
>
> https://launchpad.net/~yuri-sucupira/+archive/ubuntu/thunar1.6.10-patched
>
> However, I noticed that APT is considering "1.6.10-2ubuntu1" as a newer
> version than my "1.6.10-2ubuntu1~patch1" version. Does anyone know how I
> shall version my packages, in order to make APT choose them instead of those
> in version 1.6.10-2ubuntu1?

Hey Yuri,

Well done. I unfortunately can't test because I'm sadly still running Wily, but by the sounds of it we're all grateful for your contribution.

[Yuri Ribeiro Sucupira (yuri-sucupira)]

(In reply to Kip from comment #124)
> (In reply to Yuri R. Sucupira from comment #123)
> > After a LOT of pain (it took me some hours) I finally managed to sign my
> > sources and upload'em to a PPA. Here's the PPA:
> >
> > https://launchpad.net/~yuri-sucupira/+archive/ubuntu/thunar1.6.10-patched
> >
> > However, I noticed that APT is considering "1.6.10-2ubuntu1" as a newer
> > version than my "1.6.10-2ubuntu1~patch1" version. Does anyone know how I
> > shall version my packages, in order to make APT choose them instead of those
> > in version 1.6.10-2ubuntu1?
>
> Hey Yuri,
>
> Well done. I unfortunately can't test because I'm sadly still running Wily,
> but by the sounds of it we're all grateful for your contribution.

You're welcome. :)

[Main-haarp (main-haarp)]

Could we please keep the support and packaging stuff to a minimum here?

I appreciate the work people do on getting these critical fixes packaged, but this isn't a support forum. This section is for the bug itself.

[Yuri Ribeiro Sucupira (yuri-sucupira)]

> After a LOT of pain (it took me some hours) I finally managed to sign my
> sources and upload'em to a PPA. Here's the PPA:
>
> https://launchpad.net/~yuri-sucupira/+archive/ubuntu/thunar1.6.10-patched
>
> However, I noticed that APT is considering "1.6.10-2ubuntu1" as a newer
> version than my "1.6.10-2ubuntu1~patch1" version. Does anyone know how I
> shall version my packages, in order to make APT choose them instead of those
> in version 1.6.10-2ubuntu1?

I fixed this issue. I had to delete the PPA and create a new one. Here's the new PPA:

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

I already tested it: if you add this PPA (which supports both 32-bit/i386 and 64-bit/amd64 systems) and run `sudo apt (dist-)upgrade` it will upgrade Thunar with the patched debs.

[Yuri Ribeiro Sucupira (yuri-sucupira)]

(In reply to haarp from comment #126)
> Could we please keep the support and packaging stuff to a minimum here?
>
> I appreciate the work people do on getting these critical fixes packaged,
> but this isn't a support forum. This section is for the bug itself.

Ok, sorry.

Well, if anyone doesn't manage to add my PPA or experience some difficulty while doing it, e-mail me (in order to avoid flooding this bug report).

[Yuri Ribeiro Sucupira (yuri-sucupira)]

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

Thank you for creating the PPA.

[Yuri Ribeiro Sucupira (yuri-sucupira)]

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

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.

[Simon Steinbeiß (ochosi)]

@poma: quoting from the only open issue at https://github.com/rgcjonas/thunar-gtk3: "Thunar-gtk3 is a personal research project which is kind of abandoned at this point and likely not going anywhere."
This doesn't sound like something which you want to merge to master.

[Ketetefid (ketetefid)]

I have applied the patch (in my Gentoo system) and have intensively tested it. Not even a single crash since 3 weeks ago. I do a lot of moving and renaming every day and I always try to do it differently to trigger any crash, but thunar has become really robust.
It seems that we can close this bug, if the others agree.

Off-topic (sorry): For the sake of God, please do not lose the usability of XFCE components over any other thing. Let it be the sole DE that prioritize the usability. Who cares about porting to GTK3? I am sure that a lot of people prefer a zero-bugged XFCE in GTK2 rather than a bug-ridden GTK3 port. Please kindly focus on closing as many bugs as possible first. We have much time for porting things later.

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

I just tested patch #6779: It fixes the issue, but thunar becomes unresponsive for me when trying to access another filesystem like a USB drive. This does not happen with #6530 and #6778, which also seem to fix the problem (I didn't test extensively, though).

[Kip Warner (kip)]

Hey Yuri. I just tried your Thunar packages for Yakkety and I can confirm that I am unable to reproduce the crash we've all been having on file / directory rename.

[Yuri Ribeiro Sucupira (yuri-sucupira)]

(In reply to Kip from comment #132)
> Hey Yuri. I just tried your Thunar packages for Yakkety and I can confirm
> that I am unable to reproduce the crash we've all been having on file /
> directory rename.

Glad to hear that. I had only Xenial (*Ubuntu 16.04) packages on that PPA, but I've recently uploaded the Yakkety (*Ubuntu 16.10) and Wily (*Ubuntu 15.10) contents. I can confirm that after 1 month of testing I haven't experienced a single Thunar crash on Xenial. And now Kip confirmed that Yakkety isn't crashing either, after the update using the PPA. It seems likely that this patch will also work for Wily.

I'm not experiencing the issue reported by Andreas (Thunar becoming unresponsive when trying to access another filesystem), I'm not sure why he's going through this kind of problem.

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

I forgot to mention that I am on an x64 Arch Linux machine (current as of today). an strace (with patch #6779 applied) gives:

write(4, "\1\0\0\0\0\0\0\0", 8) = 8
recvmsg(5, {msg_namelen=0}, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
inotify_rm_watch(14, 5) = 0
futex(0x7fa94ca47a60, FUTEX_WAKE_PRIVATE, 1) = 1
inotify_rm_watch(14, 6) = 0
futex(0x7fa94ca47a60, FUTEX_WAKE_PRIVATE, 1) = 1
lstat("/path/to/directory", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
inotify_add_watch(14, "/path/to/directory", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = 18
futex(0x69f4f8, FUTEX_WAIT_PRIVATE, 2, NULL

And there it stops and becomes unresponsive.

[Yves-Alexis Perez (corsac)]

(In reply to Andreas Böhler from comment #134)
> I forgot to mention that I am on an x64 Arch Linux machine (current as of
> today). an strace (with patch #6779 applied) gives:
>
> write(4, "\1\0\0\0\0\0\0\0", 8) = 8
> recvmsg(5, {msg_namelen=0}, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource
> temporarily unavailable)
> inotify_rm_watch(14, 5) = 0
> futex(0x7fa94ca47a60, FUTEX_WAKE_PRIVATE, 1) = 1
> inotify_rm_watch(14, 6) = 0
> futex(0x7fa94ca47a60, FUTEX_WAKE_PRIVATE, 1) = 1
> lstat("/path/to/directory", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> inotify_add_watch(14, "/path/to/directory",
> IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DEL
> ETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = 18
> futex(0x69f4f8, FUTEX_WAIT_PRIVATE, 2, NULL
>
> And there it stops and becomes unresponsive.

Yup, I can confirm that. I've pushed the attachment #6779 to Debian and got similar reports, and can confirm it myself. It happens when accessing a removable device, for example.

[jEsuSdA (listas-jesusda)]

I can confirm the freezes when external USB pendrive is connected. :_(

[Dani (damufo)]

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

still present in 16.10 with thunar 1.6.10 also.

[cyrille borne (cyrille)]

same here in Xubuntu 16.10

[Yuri Ribeiro Sucupira (yuri-sucupira)]

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

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

[Lucho Nacho (livalenz)]

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

[Lucho Nacho (livalenz)]

And forgot to say thank you!

[dnord (dnord)]

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

[John Carmack (john.carmack)]

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

[John Carmack (john.carmack)]

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

[Massimo-burcheri (massimo-burcheri)]

I completely agree. Most things people do with a filemanager is moving and naming files. I looked out for other filemanagers like nautilus, xfe, spacefm, gentoo, pcmanfm, etc. I would like to stay with the Xfce default as I generally like it, but the importance or severity of this bug must be increased as it blocks a fundamental feature of any filemanager.

[Massimo-burcheri (massimo-burcheri)]

Please check for duplicates: #12260, #10805

[Sylvain Viart (sylvain-viart)]

Got it on xubuntu 16.10, still here.

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

[WebDawg (webdawg)]

Archlinux Latest....always crashing.

[Norman (normal-norman)]

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

[Weiller (weillerronfini)]

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

[Slumbergod-n (slumbergod-n)]

@Yuri. Thunar hangs for me trying to view the contents of a newly inserted flash drive.

[Yuri Ribeiro Sucupira (yuri-sucupira)]

(In reply to slumbergod from comment #141)
> @Yuri. Thunar hangs for me trying to view the contents of a newly inserted
> flash drive.

This is weird. I mean: I'm running 64-bit XUbuntu 16.04.1 LTS with Thunar 1.6.10-2ubuntu1+patch1 installed from my PPA (https://launchpad.net/~yuri-sucupira/+archive/ubuntu/thunar1.6.10-fix) and I'm experiencing no issues at all. I've already tested 2 different USB flash drives (a 4GB USB Kingston flash drive and a 32GB USB Sandisk flash drive) with "msdos" and "gpt" partition tables and "fat32" and "ext4" partitions, yet they always mount correctly and Thunar never crashes, hangs nor freezes, no matter how many times I eject and mount these flash drives again and how many file/folder move/rename operations I make Thunar to perform at these file systems. I also mount remotely shared folders from a samba (SMB) server and again Thunar behaves as it's supposed to.

Maybe it's not related to Thunar itself. I'm currently using the generic stable vanilla kernel version 4.7.10 available at http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.10/

64-bit users may want to download and install the AMD64 DEBs:
* linux-headers-4.7.10-040710_4.7.10-040710.201610220847_all.deb
* linux-headers-4.7.10-040710-generic_4.7.10-040710.201610220847_amd64.deb
* linux-image-4.7.10-040710-generic_4.7.10-040710.201610220847_amd64.deb

32-bit users may want to download and install the I386 DEBs:
* linux-headers-4.7.10-040710_4.7.10-040710.201610220847_all.deb
* linux-headers-4.7.10-040710-generic_4.7.10-040710.201610220847_i386.deb
* linux-image-4.7.10-040710-generic_4.7.10-040710.201610220847_i386.deb

Unfortunately, I'm not a developer, hence I can't fix Thunar myself: all I did was to pick Roy Richardson's patch, created the "patched" source code, sign it and upload it to a PPA I created. If upgrading the kernel to version 4.7.10 doesn't solve the issue I don't think I'll be of any help, sorry. :\

[Yomito (yomito)]

My experience:
I'm using Mint XFCE 18 x64 since a couple of months and Thunar is working correctly. This distro uses a version of Thunar called 1.6.10-3mint1.
On any other modern distro that I tried and includes Thunar 1.6.10 (MX16, Xubuntu16.04, LinuxLite3, etc) the file manager is buggy. Mint 18 is the only exception I found.
Old distros with Thunar 1.6.3 worked correctly.
It seems that, fortunately, Mint team found a solution for the buggy Thunar 1.6.10, but I'm not a programmer, just a user, so I don't know what it is.
I hope this help you.

[Yomito (yomito)]

Addendum:
Kernel on Mint 18 is 4.4.0-xx

[Slumbergod-n (slumbergod-n)]

@yuri. Thanks Yuri, I appreciated the PPA. Much easier to test. After some additional testing:

kernel 4.9.4 patched Thunar hangs when trying to view contents on newly inserted flash drive.

kernel 4.7.10 same. Thunar hangs. Can't mount or view contents.

BUT I have discovered that thunar only hangs if the icon for it is clicked from Devices on Thunar's Side Bar. If I click the Places icon I have on one of my panels and select the flash drive, Thunar opens it without any problems.

Perhaps someone else can test this to confirm this behaviour.

[Peter Feichtinger (shippo)]

Please file another bug for that issue and stop spamming the comments for this one.

[Kip Warner (kip)]

(In reply to Peter Feichtinger from comment #146)
> Please file another bug for that issue and stop spamming the comments for
> this one.

Peter, please remember your manners.

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

[Kent Lion (klsu)]

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.

[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

[Kenneth Wrede (kennethwrede)]

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

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

[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

[Sean Davis (bluesabre)]

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

[Sean Davis (bluesabre)]

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

[Łukasz Zemczak (sil2100)]

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

[Łukasz Zemczak (sil2100)]

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!

[Łukasz Zemczak (sil2100)]

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

Updated to Thunar 1.6.11 in 16.04.

Fixes the bug for me.

[Kev Bowring (flocculant)]

Updated to Thunar 1.6.11 in 16.10.

Fixes the bug for me.

verification tag left as -done

[Fidelis Sigmaring (stfidelis-deactivatedaccount)]

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

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

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

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

[Yuri Ribeiro Sucupira (yuri-sucupira)]

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

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

[Yuri Ribeiro Sucupira (yuri-sucupira)]

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

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

[Yuri Ribeiro Sucupira (yuri-sucupira)]

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.

[Kev Bowring (flocculant)]

@yuri-sucupira - point. I've added step 11 to https://wiki.ubuntu.com/QATeam/PerformingSRUVerification#How_to_perform_the_test

[N H (thenh813)]

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.

[Launchpad Janitor (janitor)]

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

[Chris Halse Rogers (raof)]

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

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

[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