Good day! 1. Open 'sftp://host/existing_folder' in Thunar. 2. Remove 'existing_folder' on 'host' (e.g. via SSH). 3. Refresh Thunar window via <F5>. 4. Result: crash.
Thanks for reporting ! I cannot reproduce the bug .. neither with thunar 1.6.17, nor with latest 4.14 branch or master. Tried with icon and tree-view. Could you please try if the bug still happens for you on thunar 1.8.9 ? (Ideally try as well to compile thunar master ) It as well would help alot to have a backtrace. See here for a distro specific manual: https://docs.xfce.org/contribute/bugs/start
I confirm this bug on thunar-1.6.16.
As RodionD said in private chat, there is no crash in 1.8.9. But: 1. Address changes to parent folder's path 2. Folder's view is emptty (bug #14761 ?) 3. On second <F5> folder's view from p.2 becomes normal
alexxcons, > I cannot reproduce the bug .. neither with thunar 1.6.17 Did you use a standard gvfs for mounting? > It as well would help alot to have a backtrace. no, sorry, my Thunar is not a debug version. But I'm attaching STDERR. Is 1.6 version maintainable?
Created attachment 9032 STDERR log
(In reply to Alexander Kurakin from comment #4) > > I cannot reproduce the bug .. neither with thunar 1.6.17 > Did you use a standard gvfs for mounting? gvfs version: 1.38.1-5 I usually test sftp stuff by going to a local folder via gvfs: sftp://schwinn@localhost/home/schwinn/software/thunar_test/ > > It as well would help alot to have a backtrace. > no, sorry, my Thunar is not a debug version. But I'm attaching STDERR. Sorry, but the STDERR does not help much here > Is 1.6 version maintainable? Only for critical bugs .. so in this case yes, a crash is a critical bug
Ok, installed debug version. Glib issue? (I'm attaching core dump.)
Core dump: https://gist.github.com/kuraga/f877d28f8c9d29be6f03bd3a1ba5684a/raw/ac53f05e8545cc1bb4b6e14591760733254f754c/core.xz P.S.: GLib 2.60.6
Afaik I cannot debug coredumps from foreign systems. Please use gdb to get a backtrace out of it. In short: gdb <path to thunar binary> <path to coredump> -- now reproduce the crash -- type "bt" in gdb Here a more complete manual: https://stackoverflow.com/q/8305866/1599887
#0 0x00007f344ec2f5d2 in g_file_monitor_directory (file=0x51, flags=flags@entry=G_FILE_MONITOR_SEND_MOVED, cancellable=cancellable@entry=0x0, error=error@entry=0x0) at ../glib-2.60.6/gio/gfile.c:5399 #1 0x0000560e85fa9cd1 in thunar_folder_finished (job=job@entry=0x7f343402b5a0 [ThunarSimpleJob], folder=0x560e8738a240) at thunar-folder.c:585 #6 0x00007f344eb9b70b in <emit signal ??? on instance 0x7f343402b5a0 [ThunarSimpleJob]> (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at ../glib-2.60.6/gobject/gsignal.c:3447 #2 0x00007f344eb7fc79 in g_cclosure_marshal_VOID__VOID (closure=0x560e877bfac0, return_value=<optimized out>, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=<optimized out>) at ../glib-2.60.6/gobject/gmarshal.c:117 #3 0x00007f344eb7dd7a in g_closure_invoke (closure=0x560e877bfac0, return_value=return_value@entry=0x0, n_param_values=1, param_values=param_values@entry=0x7ffd32025240, invocation_hint=invocation_hint@entry=0x7ffd320251c0) at ../glib-2.60.6/gobject/gclosure.c:810 #4 0x00007f344eb922b6 in signal_emit_unlocked_R (node=node@entry=0x560e8762efb0, detail=detail@entry=0, instance=instance@entry=0x7f343402b5a0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffd32025240) at ../glib-2.60.6/gobject/gsignal.c:3635 #5 0x00007f344eb9b491 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7ffd320253e0) at ../glib-2.60.6/gobject/gsignal.c:3391 #7 0x00007f3450573321 in () at /usr/lib64/libexo-1.so.0 #8 0x00007f344ea92b27 in g_idle_dispatch (source=source@entry=0x7f343402f2b0, callback=<optimized out>, user_data=<optimized out>) at ../glib-2.60.6/glib/gmain.c:5627 #9 0x00007f344ea9389a in g_main_dispatch (context=context@entry=0x560e87258090) at ../glib-2.60.6/glib/gmain.c:3189 #10 0x00007f344ea9638f in g_main_context_dispatch (context=context@entry=0x560e87258090) at ../glib-2.60.6/glib/gmain.c:3854 #11 0x00007f344ea9650b in g_main_context_iterate (context=0x560e87258090, block=block@entry=1, dispatch=dispatch@entry=1, self=self@entry=0x560e8730fc60) at ../glib-2.60.6/glib/gmain.c:3927 #12 0x00007f344ea96889 in g_main_loop_run (loop=0x560e8763c140) at ../glib-2.60.6/glib/gmain.c:4123 #13 0x00007f344f7e4577 in gtk_main () at /usr/lib64/libgtk-x11-2.0.so.0 #14 0x0000560e85f910dc in main (argc=<optimized out>, argv=<optimized out>) at main.c:312
Thanks for the coredump ! Using a real sftp connection + the tree-view I can now as well reproduce the bug Will try to debug it when I have time.
Can be reproduced as well on thunar master and on 4.14 branch. It happens for tree-view and bookmark-view. It does not always happen ... usually I need 3 to 5 attempts. On most remote connections, like sftp, no file-monitor is available. So thunar does not realize that the displayed folder does not exists any more. (That's why on local file-systems thunar directly jumps to the parent, without F5) My quess would be, that the containing folder does not reload its files from scratch on a "F5", but instead relies on some old info, containing the deleted folder ... to be further debugged ( thunar_standard_view_reload )
Created attachment 9052 WIP patch thunar_file_exists(file) is able to correctly tell if the current folder exists. So I quess it would be a good idea to only reload the folder, if it exists. Here a first WIP patch.
Created attachment 9053 patch Here a working patch which handles the case gracefully (jumping back to the parent folder on F5 by using thunar_standard_view_current_directory_destroy) Could you please take a try for the patch and let me know if it fixes the bug for you as well ?
Yes, it works! And seems like it fixes bug #14761 , also. Thanks!!!!!!!
Alexander Schwinn referenced this bugreport in commit e2968d2a133932a7609a6de4b0cc3549ed0ccc2f Crash on refresh if remote folder has been removed (Bug #15961) https://git.xfce.org/xfce/thunar/commit?id=e2968d2a133932a7609a6de4b0cc3549ed0ccc2f
Alexander Schwinn referenced this bugreport in commit 62d8e6de9fffd3d30fc89c6e02e59f47c27908a4 Crash on refresh if remote folder has been removed (Bug #15961) https://git.xfce.org/xfce/thunar/commit?id=62d8e6de9fffd3d30fc89c6e02e59f47c27908a4
Alexander Schwinn referenced this bugreport in commit 28ae8789af1ce0ce67515d6c9d320283c7595788 Crash on refresh if remote folder has been removed (Bug #15961) https://git.xfce.org/xfce/thunar/commit?id=28ae8789af1ce0ce67515d6c9d320283c7595788
Great, thanks for testing ! I pushed the fix to master , the 4.14 branch and the 4.12 branch. 1.6.18 probably will be the last release of the 4.12 branch ... since I have trouble building the thunar-apr plugin for 4.12 now : > libtool: error: '/usr/lib/x86_64-linux-gnu/libfreetype.la' is not a valid libtool archive Probably related to my upgrade to debian-testing. Even debian stable now runs thunar 1.8.x. So I guess most users anyhow already use that.
*** Bug 14761 has been marked as a duplicate of this bug. ***
Now bug #16246 is actual.