Created attachment 6482 Backtrace Thunar randomly crashes (SIGSEGV) when renaming files. Reproducible: Random Steps to Reproduce: 1. Start up Thunar. 2. Go to some directory with single file. 3. Rename that file 4. Change the filename and press enter. 5. Not crashed? Try step 3 again. Crashes even for single file in whole folder. It is strange that if you run it with gdb then the crash is not so often. gdb backtrace attached - it is strange that the thunar_file_compare_by_name() function is called even for only one file in working directory - both file_a->collate_key_nocase and file_b->collate_key_nocase are NULL. I noticed that sometimes this function is not called, but when it is (it is random), then it crashes.
Created attachment 6483 check-thunar-file-instance-when-comparing-filenames.patch > gdb backtrace attached - it is strange that the > thunar_file_compare_by_name() function is called even for only one file in > working directory - both file_a->collate_key_nocase and > file_b->collate_key_nocase are NULL. I noticed that sometimes this function > is not called, but when it is (it is random), then it crashes. This is probably related to threading issues and timing-specific. Something needs to be protected to avoid being accessed when it shouldn't be. Likely the old file is in the process of being destroyed while being compared with the new file or something like that. Does the attached workaround prevent the crashes? It is not a proper fix we can apply, but until we have a good solution it could help.
(In reply to Harald Judt from comment #1) > Created attachment 6483 > check-thunar-file-instance-when-comparing-filenames.patch > > > gdb backtrace attached - it is strange that the > > thunar_file_compare_by_name() function is called even for only one file in > > working directory - both file_a->collate_key_nocase and > > file_b->collate_key_nocase are NULL. I noticed that sometimes this function > > is not called, but when it is (it is random), then it crashes. > > This is probably related to threading issues and timing-specific. Something > needs to be protected to avoid being accessed when it shouldn't be. Likely > the old file is in the process of being destroyed while being compared with > the new file or something like that. > It can be the reason why running Thunar with gdb has about 10 times less crashes. I also noticed that sometimes, when I rename file, there appears second file with the same name like the first one (checked it with "ls -l" - there is only one real file). > Does the attached workaround prevent the crashes? It is not a proper fix we > can apply, but until we have a good solution it could help. Well, this workaround does not help. The problem is that THUNAR_IS_FILE returns true (for file_a and file_b), but pointers to collate_key are NULL. There has to be another test if file_a->collate_key or file_a->collate_key are NULL. I wonder what makes my system different it crash so often.
By the way, this bug could be related to https://bugzilla.xfce.org/show_bug.cgi?id=12253 (I did not noticed it while I was opening this bug)
I would like to confirm this bug which I noticed after the upgrade from Xubuntu 15.04 to Xubuntu 15.10. The workaround is to click the rename button with the mouse instead of using the Enter key after setting the new filename.
(In reply to Rafael Gattringer from comment #4) > I would like to confirm this bug which I noticed after the upgrade from > Xubuntu 15.04 to Xubuntu 15.10. The workaround is to click the rename button > with the mouse instead of using the Enter key after setting the new filename. Not for me it isn't. I am finding that clicking the rename button is failing about 50-75% of the time and crashing the Thunar window the same as hitting enter. This is a real problem when trying to rename a lot of files... :-/
This may not be a Thunar problem. This may be due to a recent upgrade to glib2. See here, particularly comment #12: https://bbs.archlinux.org/viewtopic.php?id=203663 And here: https://bugs.archlinux.org/task/46666 I am running Manjaro with the XFCE GUI. My laptop and desktop both have the same version of Manjaro, same 4.1 kernel, and the same version of Thunar, yet the laptop isn't having the problem. I just checked and my laptop version of glib2 is glib2-2.44.1-1- the one the commenter said is stable. Yes, he's talking about drag and drop- but the fact that my laptop with the earlier version of glib2 doesn't exhibit the problem can't be a coincidence. I don't have my desktop computer on right now- the one that IS having the problem- but I'll bet that when I turn it on tomorrow and check- my version of glib2 will be the newer problematic one, glib2-2.46.0-2.
Created attachment 6515 dont-unref-null.patch While investigating the bug I came across a glib-critical. Attached is a simple patch which fixes this critical, but probably not the bug itself. Nevertheless it might be somehow related so I post it here.
Sure enough, I checked and my desktop had the problematic version of glib2- glib2-2.46.0-2. I installed the latest round of Manjaro updates, bringing glib2 up to glib2-2.46.1-1. It's still crashing. The new version isn't stable either. The only stable version has been glib2-2.44.1-1. Somebody on the Manjaro forum posted this workaround: https://tunwinnaing.wordpress.com/2015/04/01/workaround-thunar-file-manager-crash-on-moving-files/ I didn't have the option enabled in Thunar, so I checked the box to enable it. So far it is working. Whether or not this will still work after a reboot I don't know, but I was just able to do a dozen folder & file renames without Thunar crashing.
(In reply to Harald Judt from comment #1) > > gdb backtrace attached - it is strange that the > > thunar_file_compare_by_name() function is called even for only one file in > > working directory - both file_a->collate_key_nocase and > > file_b->collate_key_nocase are NULL. I noticed that sometimes this function > > is not called, but when it is (it is random), then it crashes. > > This is probably related to threading issues and timing-specific. Something > needs to be protected to avoid being accessed when it shouldn't be. Likely > the old file is in the process of being destroyed while being compared with > the new file or something like that. I have a similar or identical backtrace to the one posted in the original bug report. I also cannot rename files without thunar going away on me. I don't know if it helps at all, but I used gdb to print some extra info from the last stack frame reached in thunar. I hope the Xfce team can solve this soon, because I have to sort out some old backed-up directories and I'm used to using thunar to do this sort of work! (gdb) frame 1 #1 0x000055555559188d in thunar_file_compare_by_name (file_a=0x555555d3e390, file_b=0x555555d2dd00, case_sensitive=<optimized out>) at thunar-file.c:4027 4027 result = strcmp (file_a->collate_key, file_b->collate_key); (gdb) info frame Stack level 1, frame at 0x7fffffffd380: rip = 0x55555559188d in thunar_file_compare_by_name (thunar-file.c:4027); saved rip = 0x55555559fd9e called by frame at 0x7fffffffd3b0, caller of frame at 0x7fffffffd360 source language c. Arglist at 0x7fffffffd360, args: file_a=0x555555d3e390, file_b=0x555555d2dd00, case_sensitive=<optimized out> Locals at 0x7fffffffd360, Previous frame's sp is 0x7fffffffd380 Saved registers: rbx at 0x7fffffffd368, rbp at 0x7fffffffd370, rip at 0x7fffffffd378 (gdb) print *file_a $2 = {__parent__ = {g_type_instance = {g_class = 0x55555588d4b0}, ref_count = 3, qdata = 0x555555e1ce80}, info = 0x7fffe00124c0, kind = G_FILE_TYPE_REGULAR, gfile = 0x555555dfe160, content_type = 0x555555d85050 "image/jpeg", icon_name = 0x0, custom_icon_name = 0x0, display_name = 0x7fffd400b7f0 "p73.jpg", basename = 0x7fffd4011680 "p73.jpg", thumbnail_path = 0x555555e3acc0 "/home/ad/.cache/thumbnails/normal/87903c1cff4c5d32097076c5ddf5686e.png", collate_key = 0x7fffd4009070 "S\001\030\001\t\001\001\001\002:73\001\001\001\001MSJ\001\030\030\030\001\t\t\t", collate_key_nocase = 0x7fffd4009070 "S\001\030\001\t\001\001\001\002:73\001\001\001\001MSJ\001\030\030\030\001\t\t\t", flags = (THUNAR_FILE_FLAG_THUMB_MASK | THUNAR_FILE_FLAG_IS_MOUNTED)} (gdb) print *file_b $3 = {__parent__ = {g_type_instance = {g_class = 0x55555588d4b0}, ref_count = 11, qdata = 0x555555dffd90}, info = 0x0, kind = G_FILE_TYPE_UNKNOWN, gfile = 0x7fffd4010f00, content_type = 0x0, icon_name = 0x0, custom_icon_name = 0x0, display_name = 0x0, basename = 0x0, thumbnail_path = 0x0, collate_key = 0x0, collate_key_nocase = 0x0, flags = THUNAR_FILE_FLAG_IS_MOUNTED}
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 <danw@gnome.org> AuthorDate: Sat Oct 24 10:37:22 2015 -0400 Commit: Dan Winship <danw@gnome.org> CommitDate: Tue Oct 27 09:51:12 2015 -0400 gtask: re-fix tasks-blocking-other-tasks The new "slowly add more task threads" code doesn't fully deal with apps that queue lots and lots of tasks which then block on tasks from their task threads. Fix this by bringing back the "task is blocking other task" check and making sure that such tasks get bumped to the front of the queue. https://bugzilla.gnome.org/show_bug.cgi?id=687223 If I am wrong about the problem being fixed, I apologize for getting anyone's hopes up. The simple test I made just now would easily have caused Thunar to crash and disappear before, so I thought I would mention the glib2.0 update so that other people can confirm (or refute) that it helps them.
(In reply to Dave Witbrodt from comment #10) > Tonight my distribution (Debian) made an update of glib2.0 available; I > changed from Debian package libglib2.0-0 version 2.46.1-2 to version > 2.46.2-1. A quick test revealed that I was not able to cause Thunar to > crash by copying many files to a temporary test directory and renaming all > of them one at a time. I was wrong. Thunar is still crashing as before. I must have simply been getting lucky last night, and never triggered the bug. Sorry for the false hope to anyone reading comment #10.
The workaround I posted in comment #8 survived 1 reboot. After the second reboot Thunar started crashing again. :-[
On #12253 (which is probably a dupe) someone bisected it down to this glib commit: https://git.gnome.org/browse/glib/commit/?id=779c809a3d07fca6c1da4f87d4ce6cf7f2d95608 This removes a 1 second delay on inotify events, quite possibly triggering race conditions in Thunar. This is probably also causing #12260
Created attachment 6530 0001-Deactivate-SEND_MOVED-code-paths.patch For a start, deactivating the SEND_MOVED code paths seems to get rid of the crashes on my system with glib-2.46.2. Please try the patch attached and report back if it fixes the crashes for you too. Why this will not solve the real issue(s), it could give some clues where to look at.
This patch fixes the file rename crash on my system as well (thunar 1.6.10git-87c2b0e and glib2 2.46.1-1). It also seems to fix the other intermittent crash when drag and dropping files/folders (https://bugzilla.xfce.org/show_bug.cgi?id=11983 & https://bugzilla.xfce.org/show_bug.cgi?id=12283). Test briefly with both "Thunar --deamon" running and not. Will continue testing.
*** Bug 12260 has been marked as a duplicate of this bug. ***
*** Bug 12290 has been marked as a duplicate of this bug. ***
*** Bug 12253 has been marked as a duplicate of this bug. ***
*** Bug 12283 has been marked as a duplicate of this bug. ***
*** Bug 12293 has been marked as a duplicate of this bug. ***
(In reply to Harald Judt from comment #14) > Created attachment 6530 > 0001-Deactivate-SEND_MOVED-code-paths.patch > > For a start, deactivating the SEND_MOVED code paths seems to get rid of the > crashes on my system with glib-2.46.2. Please try the patch attached and > report back if it fixes the crashes for you too. Why this will not solve the > real issue(s), it could give some clues where to look at. I think I can also confirm that your patch fixes this problem (Thunar 1.6.10git-a1e7371, glib2 2.46.1-1). No more crashes since then!
Created attachment 6531 Clang's ThreadSanitizer seemingly useful report I compiled Thunar (1.6.10git-6407141) with clang and -fsanitize=thread and it seems to have found the race that causes these crashes. (It also likes to report a lot of what I assume are false positives; I've left those out.)
*** Bug 12312 has been marked as a duplicate of this bug. ***
(In reply to Harald Judt from comment #14) > 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. 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.
(In reply to Harald Judt from comment #14) > 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. This fixed the problem for me as well. It also fixed the other issue mentioned by Dave Witbrodt in #24. Thanks for looking into this bug.
I forgot to mention that I have glib2 version 2.46.2 on Slackware 64bit -current.
I just have noticed something new that could help: Thunar just crashed while a cron script renamed a file in an open folder. This indicates that updating the folder view is the problem, not the rename operation.
Hi, any progress on that one?
It happens to me too. Please let me know if you need more info.
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.
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.
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
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.
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.
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.
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.
Oh, sorry, which bug should I be following up on?
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?
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.
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.
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?
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.
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
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
Still present in xubutu 16.04 LTS
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.
@ 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)
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
@ 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.
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?)
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.
No success changing thunar default view to compact list. It crashed after a few file moves.
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.
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!
Created attachment 6658 Martin's Patched Thunar Binary
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!
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?
> 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.
Sorry, I mentioned Harald's post #30 instead of #14.
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.
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 /
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).
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.
(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.
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
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.
(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.
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).
(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.
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
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);
(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.
@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?
(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!
*** Bug 12706 has been marked as a duplicate of this bug. ***
@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" behavior. No other patches have been applied to Thunar 1.6.10 in testing. diff -Naurp Thunar-1.6.10/thunar/thunar-folder.c Thunar-1.6.10-fix/thunar/thunar-folder.c --- Thunar-1.6.10/thunar/thunar-folder.c 2016-08-03 11:58:02.076666668 +0000 +++ Thunar-1.6.10-fix/thunar/thunar-folder.c 2016-08-03 11:57:28.846666000 +0000 @@ -737,8 +737,11 @@ thunar_folder_monitor (GFileMonitor if (folder->content_type_idle_id != 0) restart = g_source_remove (folder->content_type_idle_id); - /* if we don't have it, add it if the event is not an "deleted" event */ - if (G_UNLIKELY (lp == NULL && event_type != G_FILE_MONITOR_EVENT_DELETED)) + /* if we don't have it, add it if the event is not an + * "deleted" or "moved" event */ + if (G_UNLIKELY (lp == NULL + && event_type != G_FILE_MONITOR_EVENT_DELETED + && event_type != G_FILE_MONITOR_EVENT_MOVED)) { /* allocate a file for the path */ file = thunar_file_get (event_file, NULL); 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.
(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)
(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.
(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().
At this point it almost seems less work to strip everything remotely related to renaming and rewrite it.
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)
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.
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 :)
(In reply to Roy Richardson from comment #82) > Created attachment 6767 > 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.
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?
And crashing with dragging and dropping has returned for me. I will roll back to the previous patched version I was using.
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.
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.
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.
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
*** Bug 12673 has been marked as a duplicate of this bug. ***
(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 /usr/lib/libgio-2.0.so.0 #14 0x00007ffff4b70cae in ?? () from /usr/lib/libglib-2.0.so.0 #15 0x00007ffff4b702b5 in ?? () from /usr/lib/libglib-2.0.so.0 #16 0x00007ffff48ea484 in start_thread () from /usr/lib/libpthread.so.0 #17 0x00007ffff46296dd in clone () from /usr/lib/libc.so.6
(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.
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.
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.
(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()
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.
(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
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).
(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.
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".
(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?
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 :)
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.
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.
You could have been friendlier. Instead you show yourself to be an asshole. Adios.
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.
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.
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.
(In reply to Jonathan Rennison from comment #108) > 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. 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
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..
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 ..
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.
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.
(In reply to Roy Richardson from comment #114) > 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. 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.
(In reply to xb from comment #115) > (In reply to Roy Richardson from comment #114) > > 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. > > 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.
(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.
(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 > > > 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
(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 > > > > 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.
(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. :-\
(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.
(In reply to Roy Richardson from comment #114) > 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. @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.
(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?
(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.
(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. :)
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.
> 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.
(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).
@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.
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.
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).
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.
(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.
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.
(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.
I can confirm the freezes when external USB pendrive is connected. :_(
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!!!
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.
Please check for duplicates: #12260, #10805
Archlinux Latest....always crashing.
@Yuri. Thunar hangs for me trying to view the contents of a newly inserted flash drive.
(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. :\
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.
Addendum: Kernel on Mint 18 is 4.4.0-xx
@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.
Please file another bug for that issue and stop spamming the comments for this one.
(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.
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.
Hey Peter why don't you remove yourself from all these bug reports and do the rest of us a favour.
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.
Ok gents, let's all just chill and return to focusing on the issue at hand.
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.
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)
Created attachment 6965 Fix race in thunar_file_rename and thunar_folder_monitor
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
@ 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?
@Martin Dauskardt The patch is based on the git master.
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.
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.
(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.
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.
@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.
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
@xfce@dirdi.name - 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.
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).
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);
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.
(In reply to pgkos.bugzilla from comment #167) > 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. 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)
@yves-alexis: Both patches apply cleanly on master. @pgkos: So far the test-case passes (had it run for >10mins), so nice work there!
(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
(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).
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 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". [Inferior 1 (process 2292) exited normally] (gdb) backtrace full No stack. (gdb) info registers The program has no registers now. (gdb) x/16i $pc No registers. (gdb) thread apply all backtrace (gdb) quit
Created attachment 6978 Fix crash and hang while renaming (2) @flocculant I have updated the patch - please test.
"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]
@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.
(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.
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.
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.
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)
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.
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
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
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. :)
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
I agree with comment #184. I face an app being frozen in event loop. Do we need to open a new bug?
(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.
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