Sounds as feature like "close at the end of copy". However I cannot find a way to turn it off. So I believe that's a bug. So that it pretty much. I do a copy of folder or batch of files. Then at the end of the copy Thunar closes by itself. Environment: an up to date Manjaro with actually Thunar 1.6.13
I don't think it's a feature or that Thunar is gracefully closing, rather it's very likely crashing. Please, run pkill -i thunar and launch it from terminal, watch out for any error messages.
I tried to run `pkill -i thunar` thunar openned or closed but both cases that returns nothing
I started thunar from console and repeat the bug: `[1] 8689 segmentation fault (core dumped) thunar` I could not repeat the bug: - copying single `.txt` file - copying a folder containing source code - copying single picture The bug appear when - copying large amount of pictures or video to same device or to different device
I cannot reproduce the bug. We need more precise info, in order to reproduce it. Without that we cannot fix. - How many pictures of which size did you copy - Does it crash on every copy for the specified amount of pictures, or just occasionally ? - Which view is used ( detailed view / compact view / icon view) ? - How do you trigger the copy ? Select all files and press CTRL +C + CTRL+V ? Drag and drop ? Or copy the folder ?
- How many pictures of which size did you copy For last test I did that details: - 74 items, totalling 969.1 MB - which is a mix of jpg and mp4 - including one mp4 of 675 MB I did another without videos. Still same.That represent 57 files and 174MB. - Does it crash on every copy for the specified amount of pictures, or just occasionally ? yes every copy except when containing only no-multimedia files so far - Which view is used ( detailed view / compact view / icon view) ? icon view with and without preview - How do you trigger the copy ? Select all files and press CTRL +C + CTRL+V ? Drag and drop ? Or copy the folder ? Select all files or folder then CTRL +C + CTRL+V For me that more related to the "progressing copy box". When this one appears that crashes at the end of the copy. Also the copy ends correctly. FIles are copied.
Hmm, still no success in reproducing the bug :X I as well tried with 6GB of photos / videos .. worked fine for me. Maybe a filesystem isssue ? I am using ext4 here. Could you please post the output of "df -Th" Or possibly a memory problem ? "free -mh" would be good to know.
hum... my system is on ext4 as well. There is output of `df -Th` ⇒ df -Th Filesystem Type Size Used Avail Use% Mounted on dev devtmpfs 3.9G 0 3.9G 0% /dev run tmpfs 3.9G 1.5M 3.9G 1% /run /dev/sda4 ext4 451G 374G 54G 88% / tmpfs tmpfs 3.9G 27M 3.9G 1% /dev/shm tmpfs tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup tmpfs tmpfs 3.9G 4.0K 3.9G 1% /tmp /dev/sda1 vfat 496M 34M 463M 7% /boot/efi tmpfs tmpfs 789M 8.0K 789M 1% /run/user/1000 Then I don't get what you could see with `free -mh` so I did one before the bug: ⇒ free -mh total used free shared buff/cache available Mem: 7.7G 1.8G 3.4G 352M 2.5G 5.5G Swap: 15G 0B 15G and one after the bug: ⇒ free -mh total used free shared buff/cache available Mem: 7.7G 1.8G 3.2G 357M 2.6G 5.4G Swap: 15G 0B 15G To add more information about hardware, my computer is this one: https://wiki.archlinux.org/index.php/Dell_XPS_13_(9343)
Thanks for the info ! Neither the filesystem nor the memory looks suspicious :X May I ask you to generate a codedump of the crash and attach it here, together with the executable ? Like that I could figure out where in thunar the crash happened.
yes that s sounds great! how to process?
yes that sounds great! how to process?
By default core dumps are suppressed (for most users are just a waste of space); you can enable them for a specific console with: ulimit -c <size> 1.) If you dont care for a size limit: ulimit -c unlimited 2.) Than make sure no thunar deamon is running ( quit running, than run a new one) pkill -i thunar; thunar 3.) Bring thunar to crash Something like (core dumped) 4.) Find the "core" file I hope the coredump will be written into your present folder, but this may depend on your distro / systemd E.g. here you can read some more details: https://linux-audit.com/understand-and-configure-core-dumps-work-on-linux/
PID: 14384 (thunar) UID: 1000 (mickro) GID: 1000 (mickro) Signal: 11 (SEGV) Timestamp: Mon 2018-02-19 09:42:10 CET (9min ago) Command Line: thunar Executable: /usr/bin/thunar Control Group: /user.slice/user-1000.slice/session-c2.scope Unit: session-c2.scope Slice: user-1000.slice Session: c2 Owner UID: 1000 (mickro) Boot ID: 6b55744484a14e51e121c87c5ccb4aed Machine ID: 99f4511baf3dc17d4fc0b9438e3533eb4 Hostname: amsterdam Storage: /var/lib/systemd/coredump/core.thunar.1000.6b55744484a14e51e121c87c5ccb4aed.14384.1519029730000000.lz4 Message: Process 14384 (thunar) of user 1000 dumped core. Stack trace of thread 14384: #0 0x00007f115f2f56d6 n/a (libgtk-x11-2.0.so.0) #1 0x00007f115edd6e1f n/a (libgdk-x11-2.0.so.0) #2 0x00007f115edd8180 n/a (libgdk-x11-2.0.so.0) #3 0x00007f115edd9c8a n/a (libgdk-x11-2.0.so.0) #4 0x00007f115edd9d2f n/a (libgdk-x11-2.0.so.0) #5 0x00007f115d25fe38 g_main_context_dispatch (libglib-2.0.so.0) #6 0x00007f115d260081 n/a (libglib-2.0.so.0) #7 0x00007f115d2603b2 g_main_loop_run (libglib-2.0.so.0) #8 0x00007f115f15fdf3 gtk_main (libgtk-x11-2.0.so.0) #9 0x000055a5d9bc4f60 n/a (thunar) #10 0x00007f115cc60f4a __libc_start_main (libc.so.6) #11 0x000055a5d9bc50ba n/a (thunar) Stack trace of thread 14414: #0 0x00007f115cd30879 syscall (libc.so.6) #1 0x00007f115d2a6dcd g_cond_wait_until (libglib-2.0.so.0) #2 0x00007f115d233753 n/a (libglib-2.0.so.0) #3 0x00007f115d288c76 n/a (libglib-2.0.so.0) #4 0x00007f115d28826a n/a (libglib-2.0.so.0) #5 0x00007f115cffe08c start_thread (libpthread.so.0) #6 0x00007f115cd35e7f __clone (libc.so.6) Stack trace of thread 14388: #0 0x00007f115cd2b97b __poll (libc.so.6) #1 0x00007f115d25fff3 n/a (libglib-2.0.so.0) #2 0x00007f115d2603b2 g_main_loop_run (libglib-2.0.so.0) #3 0x00007f115d8546d8 n/a (libgio-2.0.so.0) #4 0x00007f115d28826a n/a (libglib-2.0.so.0) #5 0x00007f115cffe08c start_thread (libpthread.so.0) #6 0x00007f115cd35e7f __clone (libc.so.6) Stack trace of thread 14415: #0 0x00007f115cd2b97b __poll (libc.so.6) #1 0x00007f114a98a773 n/a (libpulse.so.0) #2 0x00007f114a97bbd0 pa_mainloop_poll (libpulse.so.0) #3 0x00007f114a97c271 pa_mainloop_iterate (libpulse.so.0) #4 0x00007f114a97c301 pa_mainloop_run (libpulse.so.0) #5 0x00007f114a98a6ae n/a (libpulse.so.0) #6 0x00007f114a72981c n/a (libpulsecommon-11.1.so) #7 0x00007f115cffe08c start_thread (libpthread.so.0) #8 0x00007f115cd35e7f __clone (libc.so.6) Stack trace of thread 14387: #0 0x00007f115cd2b97b __poll (libc.so.6) #1 0x00007f115d25fff3 n/a (libglib-2.0.so.0) #2 0x00007f115d26010e g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f115d260162 n/a (libglib-2.0.so.0) #4 0x00007f115d28826a n/a (libglib-2.0.so.0) #5 0x00007f115cffe08c start_thread (libpthread.so.0) #6 0x00007f115cd35e7f __clone (libc.so.6)
Hmm, this stacktrace does not help much :X #9 0x000055a5d9bc4f60 n/a (thunar) If we would have debug symbols, a name of a method would be shown instead of n/a Could you attach the thunar coredump itself to the bug ? I quess it should be this one: /var/lib/systemd/coredump/core.thunar.1000.6b55744484a14e51e121c87c5ccb4aed.14384.1519029730000000.lz4 So I could take a try to recompile thunar 1.6.13 with debug symbols and let gdb run it together with the coredump. ( Not sure if it will work at all, since build-flags may be different, but I quess it's worth a try ) If it should fail, the next step, if you are willing to invest some work, would be to compile thunar from source on your system.
I think I am hitting the same issue. I created two directories, /tmp/a and /tmp/b, and two empty files with the same name in them. Then I copied the file from /tmp/b to /tmp/a. As soon as I tell thunar to overwrite the file, it crashes. I think this is the same bug because my stack trace is looking similar. I did compile thunar and gtk2 with debug symbols and got the following stack trace: Core was generated by `./thunar-bin'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f69dcb1d4d7 in gtk_tray_icon_manager_filter (xevent=0x7ffd9ee28e50, event=<optimized out>, user_data=0x562ab57033b0) at gtktrayicon-x11.c:400 400 else if (xev->xany.window == icon->priv->manager_window) [Current thread is 1 (Thread 0x7f69dd063980 (LWP 8107))] (gdb) bt #0 0x00007f69dcb1d4d7 in gtk_tray_icon_manager_filter (xevent=0x7ffd9ee28e50, event=<optimized out>, user_data=0x562ab57033b0) at gtktrayicon-x11.c:400 #1 0x00007f69dc5c0391 in gdk_event_apply_filters (xevent=xevent@entry=0x7ffd9ee28e50, event=event@entry=0x562ab5615200, window=window@entry=0x0) at gdkevents-x11.c:371 #2 0x00007f69dc5c193c in gdk_event_translate (display=display@entry=0x562ab53a3000, event=event@entry=0x562ab5615200, xevent=xevent@entry=0x7ffd9ee28e50, return_exposes=return_exposes@entry=0) at gdkevents-x11.c:969 #3 0x00007f69dc5c3c96 in _gdk_events_queue (display=display@entry=0x562ab53a3000) at gdkevents-x11.c:2358 #4 0x00007f69dc5c3d3e in gdk_event_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at gdkevents-x11.c:2419 #5 0x00007f69d9bad458 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #6 0x00007f69d9bad6a1 in () at /usr/lib/libglib-2.0.so.0 #7 0x00007f69d9bad9d2 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0 #8 0x00007f69dc966957 in IA__gtk_main () at gtkmain.c:1270 #9 0x0000562ab47b9258 in main (argc=1, argv=0x7ffd9ee29248) at main.c:312 (gdb) p xev $1 = (XEvent *) 0x7ffd9ee28e50 (gdb) p xev->xany $2 = {type = 28, serial = 11511, send_event = 0, display = 0x562ab5395c60, window = 46137348} (gdb) p icon->priv $3 = (GtkTrayIconPrivate *) 0xaaaaaaaaaaaaaaaa (gdb) p icon $4 = 0x562ab57033b0 (gdb) p *icon $5 = {parent_instance = {window = {bin = {container = {widget = {object = {parent_instance = {g_type_instance = {g_class = 0xaaaaaaaaaaaaaaaa}, ref_count = 2863311530, qdata = 0xaaaaaaaaaaaaaaaa}, flags = 2863311530}, private_flags = 43690, state = 170 '\252', saved_state = 170 '\252', name = 0xaaaaaaaaaaaaaaaa <error: Cannot access memory at address 0xaaaaaaaaaaaaaaaa>, style = 0xaaaaaaaaaaaaaaaa, requisition = {width = -1431655766, height = -1431655766}, allocation = {x = -1431655766, y = -1431655766, width = -1431655766, height = -1431655766}, window = 0xaaaaaaaaaaaaaaaa, parent = 0xaaaaaaaaaaaaaaaa}, focus_child = 0xaaaaaaaaaaaaaaaa, border_width = 43690, need_resize = 0, resize_mode = 1, reallocate_redraws = 1, has_focus_chain = 0}, child = 0xaaaaaaaaaaaaaaaa}, title = 0xaaaaaaaaaaaaaaaa <error: Cannot access memory at address 0xaaaaaaaaaaaaaaaa>, wmclass_name = 0xaaaaaaaaaaaaaaaa <error: Cannot access memory at address 0xaaaaaaaaaaaaaaaa>, wmclass_class = 0xaaaaaaaaaaaaaaaa <error: Cannot access memory at address 0xaaaaaaaaaaaaaaaa>, wm_role = 0xaaaaaaaaaaaaaaaa <error: Cannot access memory at address 0xaaaaaaaaaaaaaaaa>, focus_widget = 0xaaaaaaaaaaaaaaaa, default_widget = 0xaaaaaaaaaaaaaaaa, transient_parent = 0xaaaaaaaaaaaaaaaa, geometry_info = 0xaaaaaaaaaaaaaaaa, frame = 0xaaaaaaaaaaaaaaaa, group = 0xaaaaaaaaaaaaaaaa, configure_request_count = 43690, allow_shrink = 0, allow_grow = 1, configure_notify_received = 0, need_default_position = 1, need_default_size = 0, position = 5, type = 10, has_user_ref_count = 0, has_focus = 1, modal = 0, destroy_with_parent = 1, has_frame = 0, iconify_initially = 1, stick_initially = 0, maximize_initially = 1, decorated = 0, type_hint = 5, gravity = 10, is_active = 1, has_toplevel_focus = 0, frame_left = 2863311530, frame_top = 2863311530, frame_right = 2863311530, frame_bottom = 2863311530, keys_changed_handler = 2863311530, mnemonic_modifier = 2863311530, screen = 0xaaaaaaaaaaaaaaaa}, socket_window = 0xaaaaaaaaaaaaaaaa, modality_window = 0xaaaaaaaaaaaaaaaa, modality_group = 0xaaaaaaaaaaaaaaaa, grabbed_keys = 0xaaaaaaaaaaaaaaaaPython Exception <class 'gdb.error'> There is no member named keys.: , same_app = 0}, priv = 0xaaaaaaaaaaaaaaaa} (gdb) p icon[1] $1 = {parent_instance = {window = {bin = {container = {widget = {object = {parent_instance = {g_type_instance = {g_class = 0x0}, ref_count = 0, qdata = 0x6081000fb0500}, flags = 512}, private_flags = 1536, state = 5 '\005', saved_state = 0 '\000', name = 0x6060000000200 <error: Cannot access memory at address 0x6060000000200>, style = 0xf5070000010500, requisition = {width = 512, height = 16582144}, allocation = {x = 16516352, y = 722961, width = 512, height = 722432}, window = 0x4c080000040500, parent = 0x17070000000200}, focus_child = 0xea090000ff0500, border_width = 512, need_resize = 0, resize_mode = 0, reallocate_redraws = 0, has_focus_chain = 0}, child = 0x12080000020500}, title = 0xd070000000200 <error: Cannot access memory at address 0xd070000000200>, wmclass_name = 0x63090000fe0500 <error: Cannot access memory at address 0x63090000fe0500>, wmclass_class = 0xef060000000200 <error: Cannot access memory at address 0xef060000000200>, wm_role = 0xe7080000fb0500 <error: Cannot access memory at address 0xe7080000fb0500>, focus_widget = 0xed070000000200, default_widget = 0x214090100030600, transient_parent = 0x7060000000200, geometry_info = 0xf8070000010500, frame = 0x9070000000200, group = 0x22090000fc0500, configure_request_count = 512, allow_shrink = 0, allow_grow = 0, configure_notify_received = 0, need_default_position = 0, need_default_size = 0, position = 0, type = 0, has_user_ref_count = 0, has_focus = 0, modal = 0, destroy_with_parent = 0, has_frame = 0, iconify_initially = 0, stick_initially = 0, maximize_initially = 0, decorated = 0, type_hint = 0, gravity = 6, is_active = 0, has_toplevel_focus = 0, frame_left = 263424, frame_top = 14354432, frame_right = 512, frame_bottom = 1771264, keys_changed_handler = 16712960, mnemonic_modifier = 33818881, screen = 0xa060000000200}, socket_window = 0x28080000020500, modality_window = 0x11070000000200, modality_group = 0xb8090000fe0500, Python Exception <class 'gdb.error'> There is no member named keys.: grabbed_keys = 0xfa060000000200, same_app = 0}, priv = 0xf2070000000200} Looks like icon points to... data explicitly set to 0xaa. So maybe someone forgot to write actual data to it? Used versions: thunar: 1.16.4 gtk+: 2.24.32 Linux laptop 4.15.12-1-ARCH #1 SMP PREEMPT Wed Mar 21 15:14:56 UTC 2018 x86_64 GNU/Linux
Because the coredump was too large to attach, I uploaded it to https://data.jonas.stuff42.de/hackage-private/coredump.tar.gz
Thanks alot, I'll take a look at it when I have time !
Sadly I was not able to get any meaningful info out of the coredump :X ( I wonder how a tray-icon could possibly be involved .. did not find anything related in thunar ) As well I failed to reproduce the bug. Tried many times with your binary and with thunar master. If you are motivated to further debug, best start debugging in the method "thunar_transfer_job_copy_file" in "thunar-transfer-job.c". It triggers the dialog via "thunar_job_ask_replace" and handle the response. May I ask you to as well take a try for thunar master, to see if the bug still appears there for you? ( Possibly best to do that first )
Closing since we're unable to reproduce the crash and reporter didn't reply.