i do experience thunar crashes on my system. below are details. SYSTEM DETAILS: ----- [klevstul@silentGamerMjr ~]$ inxi -Fxz System: Host: silentGamerMjr Kernel: 4.14.60-1-MANJARO x86_64 bits: 64 compiler: gcc v: 8.1.1 Desktop: Xfce 4.12.4 Distro: Manjaro Linux Machine: Type: Desktop Mobo: MSI model: Z87-G45 GAMING (MS-7821) v: 1.0 serial: <filter> UEFI: American Megatrends v: 1.9 date: 07/21/2014 CPU: Topology: Quad Core model: Intel Core i7-4770S bits: 64 type: MT MCP arch: Haswell rev: 3 L2 cache: 8192 KiB flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 49623 Speed: 2028 MHz min/max: 800/3900 MHz Core speeds (MHz): 1: 2036 2: 2006 3: 2068 4: 2030 5: 2017 6: 2068 7: 2066 8: 2015 Graphics: Card-1: NVIDIA GP106 [GeForce GTX 1060 6GB] driver: nvidia v: 390.77 bus ID: 01:00.0 Display: x11 server: N/A driver: nvidia resolution: <xdpyinfo missing> OpenGL: renderer: GeForce GTX 1060 6GB/PCIe/SSE2 v: 4.6.0 NVIDIA 390.77 direct render: Yes Audio: Card-1: Intel 8 Series/C220 Series High Definition Audio driver: snd_hda_intel v: kernel bus ID: 00:1b.0 Card-2: NVIDIA GP106 High Definition Audio driver: snd_hda_intel v: kernel bus ID: 01:00.1 Card-3: N/A type: USB driver: snd-usb-audio bus ID: 3:3 Card-4: Logitech G933 Wireless Headset Dongle type: USB driver: snd-usb-audio bus ID: 3:7 Sound Server: ALSA v: k4.14.60-1-MANJARO Network: Card-1: Qualcomm Atheros Killer E220x Gigabit Ethernet driver: alx v: kernel port: d000 bus ID: 03:00 IF: enp3s0 state: up speed: 100 Mbps duplex: full mac: <filter> Drives: Local Storage: total: 5.68 TiB used: -9205357636648164124 ID-1: /dev/sda vendor: Intel model: SSDSC2BW240A4 size: 223.57 GiB ID-2: /dev/sdb vendor: Seagate model: ST2000DM001-1ER164 size: 1.82 TiB ID-3: /dev/sdc vendor: Seagate model: ST2000DM001-1ER164 size: 1.82 TiB ID-4: /dev/sdd vendor: Western Digital model: WD2003FZEX-00SRLA0 size: 1.82 TiB RAID: Device-1: md0 type: mdraid status: active Components: online: sdc~c1 sdb~c0 Info: raid: raid-10 blocks: 2930075136 report: 3/2 UU_ chunk size: 512K Partition: ID-1: / size: 184.81 GiB used: 43.27 GiB (23.4%) fs: ext4 dev: /dev/dm-0 ID-2: swap-1 size: 34.50 GiB used: 566.0 MiB (1.6%) fs: swap dev: /dev/dm-1 Sensors: System Temperatures: cpu: 29.8 C mobo: 27.8 C gpu: nvidia temp: 48 C Fan Speeds (RPM): N/A gpu: nvidia fan: 27% Info: Processes: 276 Uptime: 16d 22h 17m Memory: 31.36 GiB used: 15.84 GiB (50.5%) Init: systemd Compilers: gcc: 8.2.0 clang: 6.0.1 Shell: bash v: 4.4.23 inxi: 3.0.20 ----- ERROR LOG OUTPUT: ----- > **`journalctl -b -p 3`** > **`journalctl -b -g thunar`** ``` Aug 13 09:49:54 silentGamerMjr kernel: Thunar[1226]: segfault at 0 ip 00007f51d5507a99 sp 00007ffe8731f47> Aug 13 09:49:54 silentGamerMjr systemd-coredump[1235]: Process 1226 (Thunar) of user 1000 dumped core. Stack trace of thread 1226: #0 0x00007f51d5507a99 n/a (libgtk-3.so.0) #1 0x00007f51d53991a9 n/a (libgtk-3.so.0) #2 0x00007f51d53af3b5 n/a (libgtk-3.so.0) #3 0x00007f51d539a55d n/a (libgtk-3.so.0) #4 0x00007f51d53af2f0 n/a (libgtk-3.so.0) #5 0x00007f51d53af346 n/a (libgtk-3.so.0) #6 0x00007f51d539aef4 n/a (libgtk-3.so.0) #7 0x00007f51d3b94b60 g_type_create_instance (lib> #8 0x00007f51d3b75259 n/a (libgobject-2.0.so.0) #9 0x00007f51d3b76a7d g_object_new_with_propertie> #10 0x00007f51d3b77532 g_object_new (libgobject-2.> #11 0x00007f51d53b7a7b n/a (libgtk-3.so.0) #12 0x00007f51d559e34a n/a (libgtk-3.so.0) #13 0x00007f51d3b94b60 g_type_create_instance (lib> #14 0x00007f51d3b75259 n/a (libgobject-2.0.so.0) #15 0x00007f51d3b77180 g_object_new_valist (libgob> #16 0x00007f51d3b7750a g_object_new (libgobject-2.> #17 0x000055dc915ea8c6 n/a (thunar) #18 0x000055dc915b3061 n/a (thunar) #19 0x00007f51d3b6fa4d g_closure_invoke (libgobjec> #20 0x00007f51d3b82f18 n/a (libgobject-2.0.so.0) #21 0x00007f51d3b8b6f6 g_signal_emit_valist (libgo> #22 0x00007f51d3b8c130 g_signal_emit (libgobject-2> #23 0x00007f51d3e55cf3 g_application_register (lib> #24 0x00007f51d3e56540 n/a (libgio-2.0.so.0) #25 0x00007f51d3e568e2 g_application_run (libgio-2> #26 0x000055dc915a90cb n/a (thunar) #27 0x00007f51d329206b __libc_start_main (libc.so.> #28 0x000055dc915a91ea n/a (thunar) Stack trace of thread 1227: #0 0x00007f51d335cea9 __poll (libc.so.6) #1 0x00007f51d3895523 n/a (libglib-2.0.so.0) #2 0x00007f51d389563e g_main_context_iteration (l> #3 0x00007f51d3895692 n/a (libglib-2.0.so.0) #4 0x00007f51d38bda2a n/a (libglib-2.0.so.0) #5 0x00007f51d3632075 start_thread (libpthread.so> #6 0x00007f51d336753f __clone (libc.so.6) Stack trace of thread 1228: #0 0x00007f51d335cea9 __poll (libc.so.6) #1 0x00007f51d3895523 n/a (libglib-2.0.so.0) #2 0x00007f51d38958e2 g_main_loop_run (libglib-2.> #3 0x00007f51d3e84348 n/a (libgio-2.0.so.0) #4 0x00007f51d38bda2a n/a (libglib-2.0.so.0) #5 0x00007f51d3632075 start_thread (libpthread.so> #6 0x00007f51d336753f __clone (libc.so.6) ``` ``` Aug 16 18:27:56 silentGamerMjr kernel: traps: Thunar[2535] general protection ip:55d7808877a7 sp:7ffd5d5e> Aug 16 18:27:58 silentGamerMjr systemd-coredump[22723]: Process 2535 (Thunar) of user 1000 dumped core. Stack trace of thread 2535: #0 0x000055d7808877a7 n/a (thunar) #1 0x000055d7808c40e1 n/a (thunar) #2 0x000055d7808bf3bf n/a (thunar) #3 0x00007f70af4c8a4d g_closure_invoke (libgobje> #4 0x00007f70af4dbe40 n/a (libgobject-2.0.so.0) #5 0x00007f70af4e46f6 g_signal_emit_valist (libg> #6 0x00007f70af4e5130 g_signal_emit (libgobject-> #7 0x000055d78088b13b n/a (thunar) #8 0x00007f70af4c8a4d g_closure_invoke (libgobje> #9 0x00007f70af4dbe40 n/a (libgobject-2.0.so.0) #10 0x00007f70af4e46f6 g_signal_emit_valist (libg> #11 0x00007f70af4e5130 g_signal_emit (libgobject-> #12 0x00007f70b1edf2b2 n/a (libexo-2.so.0) #13 0x00007f70af1ee1d6 g_main_context_dispatch (l> #14 0x00007f70af1ee5b1 n/a (libglib-2.0.so.0) #15 0x00007f70af1ee63e g_main_context_iteration (> #16 0x00007f70af7af97e g_application_run (libgio-> #17 0x000055d78086b0cb n/a (thunar) #18 0x00007f70aebeb06b __libc_start_main (libc.so> #19 0x000055d78086b1ea n/a (thunar) Stack trace of thread 2537: #0 0x00007f70aecb5ea9 __poll (libc.so.6) #1 0x00007f70af1ee523 n/a (libglib-2.0.so.0) #2 0x00007f70af1ee8e2 g_main_loop_run (libglib-2> #3 0x00007f70af7dd348 n/a (libgio-2.0.so.0) #4 0x00007f70af216a2a n/a (libglib-2.0.so.0) #5 0x00007f70aef8b075 start_thread (libpthread.s> #6 0x00007f70aecc053f __clone (libc.so.6) Stack trace of thread 22715: #0 0x00007f70aecbb0f9 syscall (libc.so.6) #1 0x00007f70af23552d g_cond_wait_until (libglib> #2 0x00007f70af1c0903 n/a (libglib-2.0.so.0) #3 0x00007f70af217436 n/a (libglib-2.0.so.0) #4 0x00007f70af216a2a n/a (libglib-2.0.so.0) #5 0x00007f70aef8b075 start_thread (libpthread.s> #6 0x00007f70aecc053f __clone (libc.so.6) Stack trace of thread 2536: #0 0x00007f70aecb5ea9 __poll (libc.so.6) #1 0x00007f70af1ee523 n/a (libglib-2.0.so.0) #2 0x00007f70af1ee63e g_main_context_iteration (> #3 0x00007f70af1ee692 n/a (libglib-2.0.so.0) #4 0x00007f70af216a2a n/a (libglib-2.0.so.0) #5 0x00007f70aef8b075 start_thread (libpthread.s> #6 0x00007f70aecc053f __clone (libc.so.6) Stack trace of thread 22716: #0 0x00007f70aecbb0f9 syscall (libc.so.6) #1 0x00007f70af23552d g_cond_wait_until (libglib> #2 0x00007f70af1c0903 n/a (libglib-2.0.so.0) #3 0x00007f70af217436 n/a (libglib-2.0.so.0) #4 0x00007f70af216a2a n/a (libglib-2.0.so.0) #5 0x00007f70aef8b075 start_thread (libpthread.s> #6 0x00007f70aecc053f __clone (libc.so.6) Stack trace of thread 22714: #0 0x00007f70aecbb0f9 syscall (libc.so.6) #1 0x00007f70af23552d g_cond_wait_until (libglib> #2 0x00007f70af1c0903 n/a (libglib-2.0.so.0) #3 0x00007f70af217436 n/a (libglib-2.0.so.0) #4 0x00007f70af216a2a n/a (libglib-2.0.so.0) #5 0x00007f70aef8b075 start_thread (libpthread.s> #6 0x00007f70aecc053f __clone (libc.so.6) Stack trace of thread 22717: #0 0x00007f70aecbb0f9 syscall (libc.so.6) #1 0x00007f70af23552d g_cond_wait_until (libglib> #2 0x00007f70af1c0903 n/a (libglib-2.0.so.0) #3 0x00007f70af217436 n/a (libglib-2.0.so.0) #4 0x00007f70af216a2a n/a (libglib-2.0.so.0) #5 0x00007f70aef8b075 start_thread (libpthread.s> #6 0x00007f70aecc053f __clone (libc.so.6) Stack trace of thread 22720: #0 0x00007f70aecbb0f9 syscall (libc.so.6) #1 0x00007f70af23552d g_cond_wait_until (libglib> #2 0x00007f70af1c0903 n/a (libglib-2.0.so.0) #3 0x00007f70af217436 n/a (libglib-2.0.so.0) #4 0x00007f70af216a2a n/a (libglib-2.0.so.0) #5 0x00007f70aef8b075 start_thread (libpthread.s> #6 0x00007f70aecc053f __clone (libc.so.6) Stack trace of thread 22719: #0 0x00007f70aecbb0f9 syscall (libc.so.6) #1 0x00007f70af23552d g_cond_wait_until (libglib> #2 0x00007f70af1c0903 n/a (libglib-2.0.so.0) #3 0x00007f70af217436 n/a (libglib-2.0.so.0) #4 0x00007f70af216a2a n/a (libglib-2.0.so.0) #5 0x00007f70aef8b075 start_thread (libpthread.s> #6 0x00007f70aecc053f __clone (libc.so.6) Stack trace of thread 22718: #0 0x00007f70aecbb0f9 syscall (libc.so.6) #1 0x00007f70af23552d g_cond_wait_until (libglib> #2 0x00007f70af1c0903 n/a (libglib-2.0.so.0) #3 0x00007f70af217436 n/a (libglib-2.0.so.0) #4 0x00007f70af216a2a n/a (libglib-2.0.so.0) #5 0x00007f70aef8b075 start_thread (libpthread.s> #6 0x00007f70aecc053f __clone (libc.so.6) Stack trace of thread 22721: #0 0x00007f70aecbb0f9 syscall (libc.so.6) #1 0x00007f70af23552d g_cond_wait_until (libglib> #2 0x00007f70af1c0903 n/a (libglib-2.0.so.0) #3 0x00007f70af217436 n/a (libglib-2.0.so.0) #4 0x00007f70af216a2a n/a (libglib-2.0.so.0) #5 0x00007f70aef8b075 start_thread (libpthread.s> #6 0x00007f70aecc053f __clone (libc.so.6) ``` ``` Aug 24 23:12:08 silentGamerMjr kernel: Thunar[22744]: segfault at 48 ip 000056232abd8dd0 sp 00007fff46e03> Aug 24 23:12:09 silentGamerMjr systemd-coredump[24987]: Process 22744 (Thunar) of user 1000 dumped core. Stack trace of thread 22744: #0 0x000056232abd8dd0 n/a (thunar) #1 0x000056232abe60c7 n/a (thunar) #2 0x00007f5b9e6ecde8 n/a (libgtk-3.so.0) #3 0x00007f5b9e4d10d9 n/a (libgtk-3.so.0) #4 0x00007f5b9ca05e70 g_hash_table_foreach (libg> #5 0x00007f5b9e4d0fac n/a (libgtk-3.so.0) #6 0x00007f5b9e4d6ae9 n/a (libgtk-3.so.0) #7 0x00007f5b9e5d8cf1 n/a (libgtk-3.so.0) #8 0x00007f5b9ccf1c96 n/a (libgobject-2.0.so.0) #9 0x00007f5b9cd0d9e9 g_signal_emit_valist (libg> #10 0x00007f5b9cd0e130 g_signal_emit (libgobject-> #11 0x00007f5b9e4d2c0f gtk_cell_area_apply_attrib> #12 0x00007f5b9e700e71 n/a (libgtk-3.so.0) #13 0x00007f5b9e702e36 n/a (libgtk-3.so.0) #14 0x00007f5b9e709395 n/a (libgtk-3.so.0) #15 0x00007f5b9e0d5843 n/a (libgdk-3.so.0) #16 0x00007f5b9ca171d6 g_main_context_dispatch (l> #17 0x00007f5b9ca175b1 n/a (libglib-2.0.so.0) #18 0x00007f5b9ca1763e g_main_context_iteration (> #19 0x00007f5b9cfd897e g_application_run (libgio-> #20 0x000056232abbb0cb n/a (thunar) #21 0x00007f5b9c41406b n/a (/usr/lib/libc-2.27.so> ``` ``` Aug 29 18:24:14 silentGamerMjr kernel: traps: Thunar[25007] general protection ip:560bc28ab7a7 sp:7fffaed> Aug 29 18:24:16 silentGamerMjr systemd-coredump[27655]: Process 25007 (Thunar) of user 1000 dumped core. Stack trace of thread 25007: #0 0x0000560bc28ab7a7 n/a (thunar) #1 0x0000560bc28e80e1 n/a (thunar) #2 0x0000560bc28e33bf n/a (thunar) #3 0x00007f49cdb95a4d g_closure_invoke (libgobje> #4 0x00007f49cdba8e40 n/a (libgobject-2.0.so.0) #5 0x00007f49cdbb16f6 g_signal_emit_valist (libg> #6 0x00007f49cdbb2130 g_signal_emit (libgobject-> #7 0x0000560bc28af13b n/a (thunar) #8 0x00007f49cdb95a4d g_closure_invoke (libgobje> #9 0x00007f49cdba8e40 n/a (libgobject-2.0.so.0) #10 0x00007f49cdbb16f6 g_signal_emit_valist (libg> #11 0x00007f49cdbb2130 g_signal_emit (libgobject-> #12 0x00007f49d05b02b2 n/a (libexo-2.so.0) #13 0x00007f49cd8bb1d6 g_main_context_dispatch (l> #14 0x00007f49cd8bb5b1 n/a (libglib-2.0.so.0) #15 0x00007f49cd8bb63e g_main_context_iteration (> #16 0x00007f49cde7c97e g_application_run (libgio-> #17 0x0000560bc288f0cb n/a (thunar) #18 0x00007f49cd6ac223 __libc_start_main (libc.so> #19 0x0000560bc288f1ea n/a (thunar) Stack trace of thread 25009: #0 0x00007f49cd778bb1 __poll (libc.so.6) #1 0x00007f49cd8bb523 n/a (libglib-2.0.so.0) #2 0x00007f49cd8bb8e2 g_main_loop_run (libglib-2> #3 0x00007f49cdeaa348 n/a (libgio-2.0.so.0) #4 0x00007f49cd8e3a2a n/a (libglib-2.0.so.0) #5 0x00007f49cd853a9d start_thread (libpthread.s> #6 0x00007f49cd783a43 __clone (libc.so.6) Stack trace of thread 27650: #0 0x00007f49cd77e40d syscall (libc.so.6) #1 0x00007f49cd90252d g_cond_wait_until (libglib> #2 0x00007f49cd88d903 n/a (libglib-2.0.so.0) #3 0x00007f49cd8e4436 n/a (libglib-2.0.so.0) #4 0x00007f49cd8e3a2a n/a (libglib-2.0.so.0) #5 0x00007f49cd853a9d start_thread (libpthread.s> #6 0x00007f49cd783a43 __clone (libc.so.6) Stack trace of thread 27637: #0 0x00007f49cd77e40d syscall (libc.so.6) #1 0x00007f49cd90252d g_cond_wait_until (libglib> #2 0x00007f49cd88d903 n/a (libglib-2.0.so.0) #3 0x00007f49cd8e4436 n/a (libglib-2.0.so.0) #4 0x00007f49cd8e3a2a n/a (libglib-2.0.so.0) #5 0x00007f49cd853a9d start_thread (libpthread.s> #6 0x00007f49cd783a43 __clone (libc.so.6) Stack trace of thread 27649: #0 0x00007f49cd88c5c9 g_array_insert_vals (libgl> #1 0x00007f49cde2f282 n/a (libgio-2.0.so.0) #2 0x00007f49cde30c79 n/a (libgio-2.0.so.0) #3 0x00007f49cdec0242 n/a (libgio-2.0.so.0) #4 0x00007f49cdec279a n/a (libgio-2.0.so.0) #5 0x00007f49cdebfbe5 n/a (libgio-2.0.so.0) #6 0x00007f49cde2c87b g_file_enumerator_next_fil> #7 0x0000560bc28b60c8 n/a (thunar) #8 0x0000560bc28b591b n/a (thunar) #9 0x0000560bc28d709a n/a (thunar) #10 0x00007f49d05b01e7 n/a (libexo-2.so.0) #11 0x00007f49cde3df2e n/a (libgio-2.0.so.0) #12 0x00007f49cde66e39 n/a (libgio-2.0.so.0) #13 0x00007f49cd8e4463 n/a (libglib-2.0.so.0) #14 0x00007f49cd8e3a2a n/a (libglib-2.0.so.0) #15 0x00007f49cd853a9d start_thread (libpthread.s> #16 0x00007f49cd783a43 __clone (libc.so.6) Stack trace of thread 27653: #0 0x00007f49cd8ee430 n/a (libglib-2.0.so.0) #1 0x00007f49cd8eefe6 n/a (libglib-2.0.so.0) #2 0x00007f49cd8edf1c g_utf8_collate_key (libgli> #3 0x00007f49cd8ee1ee g_utf8_collate_key_for_fil> #4 0x0000560bc28aba7c n/a (thunar) #5 0x0000560bc28ae121 n/a (thunar) #6 0x0000560bc28b6148 n/a (thunar) #7 0x0000560bc28b591b n/a (thunar) #8 0x0000560bc28d709a n/a (thunar) #9 0x00007f49d05b01e7 n/a (libexo-2.so.0) #10 0x00007f49cde3df2e n/a (libgio-2.0.so.0) #11 0x00007f49cde66e39 n/a (libgio-2.0.so.0) #12 0x00007f49cd8e4463 n/a (libglib-2.0.so.0) #13 0x00007f49cd8e3a2a n/a (libglib-2.0.so.0) #14 0x00007f49cd853a9d start_thread (libpthread.s> #15 0x00007f49cd783a43 __clone (libc.so.6) Stack trace of thread 25008: #0 0x00007f49cd778bb1 __poll (libc.so.6) #1 0x00007f49cd8bb523 n/a (libglib-2.0.so.0) #2 0x00007f49cd8bb63e g_main_context_iteration (> #3 0x00007f49cd8bb692 n/a (libglib-2.0.so.0) #4 0x00007f49cd8e3a2a n/a (libglib-2.0.so.0) #5 0x00007f49cd853a9d start_thread (libpthread.s> #6 0x00007f49cd783a43 __clone (libc.so.6) Stack trace of thread 27652: #0 0x00007f49cd77e40d syscall (libc.so.6) #1 0x00007f49cd902411 g_cond_wait (libglib-2.0.s> #2 0x00007f49cde3e1cc g_io_scheduler_job_send_to> #3 0x00007f49d05b0618 exo_job_emit (libexo-2.so.> #4 0x0000560bc28b6da2 n/a (thunar) #5 0x0000560bc28b5959 n/a (thunar) #6 0x0000560bc28d709a n/a (thunar) #7 0x00007f49d05b01e7 n/a (libexo-2.so.0) #8 0x00007f49cde3df2e n/a (libgio-2.0.so.0) #9 0x00007f49cde66e39 n/a (libgio-2.0.so.0) #10 0x00007f49cd8e4463 n/a (libglib-2.0.so.0) #11 0x00007f49cd8e3a2a n/a (libglib-2.0.so.0) #12 0x00007f49cd853a9d start_thread (libpthread.s> #13 0x00007f49cd783a43 __clone (libc.so.6) Stack trace of thread 27651: #0 0x00007f49cd77e40d syscall (libc.so.6) #1 0x00007f49cd902411 g_cond_wait (libglib-2.0.s> #2 0x00007f49cde3e1cc g_io_scheduler_job_send_to> #3 0x00007f49d05b0618 exo_job_emit (libexo-2.so.> #4 0x0000560bc28b6da2 n/a (thunar) #5 0x0000560bc28b5959 n/a (thunar) #6 0x0000560bc28d709a n/a (thunar) #7 0x00007f49d05b01e7 n/a (libexo-2.so.0) #8 0x00007f49cde3df2e n/a (libgio-2.0.so.0) #9 0x00007f49cde66e39 n/a (libgio-2.0.so.0) #10 0x00007f49cd8e4463 n/a (libglib-2.0.so.0) #11 0x00007f49cd8e3a2a n/a (libglib-2.0.so.0) #12 0x00007f49cd853a9d start_thread (libpthread.s> #13 0x00007f49cd783a43 __clone (libc.so.6) ``` ----- related links: - https://forum.manjaro.org/t/open-thunar-exits-without-warning/56639 - https://forum.xfce.org/viewtopic.php?pid=49516#p49516
Humm, the current stacktrace does not help me much ( no line numbers since the thunar debug info is missing ) Two options which come to my mind: 1) Compile and install thunar from source with debug symbols ( ./autogen.sh --enable-debug ) so that you get more info from the backtrace next time it crashes or 2) Compress and attach your coredump to the bug, together with your thunar binary .... it might be possible to add symbols to the binary via gdb, but I am not too experienced with that. However since that will be simpler for you, we can have a try for 2) first. Possibly manjaro provides a "thunar-debug" package, which contains the stripped-off debug-sybols ?
manjaro is based on arch linux, so possibly this could help you to get debug-info into your backtrace: https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces
thanks for getting back to me this quickly. quite new in the linux realm so you might need to "hold my hand" a bit. i do not see "thunar-debug" (manjaro using aur: https://aur.archlinux.org/packages/?O=0&SeB=nd&K=thunar&outdated=&SB=n&SO=a&PP=50&do_Search=Go). however, i do find "thunar-devel 1.8.1-1" (https://aur.archlinux.org/packages/thunar-devel). do you know if that outputs any additional debug information? i did find a related post here: https://forum.xfce.org/viewtopic.php?id=12266 and executed these commands for starting thunar in debug mode: (installed gdb 8.1.1-1 / http://www.gnu.org/software/gdb/) ``` thunar -q gdb file /usr/bin/thunar run ``` please note that it says: - "Reading symbols from /usr/bin/thunar...(no debugging symbols found)...done." OUTPUT (BUT NO CRASH, YET): ``` [klevstul@silentGamerMjr ~]$ gdb GNU gdb (GDB) 8.1.1 Copyright (C) 2018 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-pc-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". (gdb) file /usr/bin/thunar Reading symbols from /usr/bin/thunar...(no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/thunar [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0x7fffec5bc700 (LWP 1545)] [New Thread 0x7fffebdbb700 (LWP 1546)] [New Thread 0x7fffeb5ba700 (LWP 1548)] [Thread 0x7fffeb5ba700 (LWP 1548) exited] [Thread 0x7fffebdbb700 (LWP 1546) exited] [Thread 0x7fffed74d980 (LWP 1532) exited] ``` found another helpful page, https://forum.xfce.org/viewtopic.php?pid=49143#p49143, with a nifty command presenting related core dump data. however, it seems similar to what i provided earler. does this mean there is no additional info in the core dump? ``` [klevstul@silentGamerMjr ~]$ coredumpctl info $(coredumpctl list | grep thunar | tail -1 | awk '{print $5}') --no-pager PID: 25007 (Thunar) UID: 1000 (klevstul) GID: 1000 (klevstul) Signal: 11 (SEGV) Timestamp: Wed 2018-08-29 18:24:14 CEST (1 day 4h ago) Command Line: /usr/bin/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 (klevstul) Boot ID: c828e8f1078d4a17a53f28dd00bea5ec Machine ID: ba12650091a2421d9094d27a8bee1b5a Hostname: silentGamerMjr Storage: /var/lib/systemd/coredump/core.Thunar.1000.c828e8f1078d4a17a53f28dd00bea5ec.25007.1535559854000000.lz4 Message: Process 25007 (Thunar) of user 1000 dumped core. Stack trace of thread 25007: #0 0x0000560bc28ab7a7 n/a (thunar) #1 0x0000560bc28e80e1 n/a (thunar) #2 0x0000560bc28e33bf n/a (thunar) #3 0x00007f49cdb95a4d g_closure_invoke (libgobject-2.0.so.0) #4 0x00007f49cdba8e40 n/a (libgobject-2.0.so.0) #5 0x00007f49cdbb16f6 g_signal_emit_valist (libgobject-2.0.so.0) #6 0x00007f49cdbb2130 g_signal_emit (libgobject-2.0.so.0) #7 0x0000560bc28af13b n/a (thunar) #8 0x00007f49cdb95a4d g_closure_invoke (libgobject-2.0.so.0) #9 0x00007f49cdba8e40 n/a (libgobject-2.0.so.0) #10 0x00007f49cdbb16f6 g_signal_emit_valist (libgobject-2.0.so.0) #11 0x00007f49cdbb2130 g_signal_emit (libgobject-2.0.so.0) #12 0x00007f49d05b02b2 n/a (libexo-2.so.0) #13 0x00007f49cd8bb1d6 g_main_context_dispatch (libglib-2.0.so.0) #14 0x00007f49cd8bb5b1 n/a (libglib-2.0.so.0) #15 0x00007f49cd8bb63e g_main_context_iteration (libglib-2.0.so.0) #16 0x00007f49cde7c97e g_application_run (libgio-2.0.so.0) #17 0x0000560bc288f0cb n/a (thunar) #18 0x00007f49cd6ac223 __libc_start_main (libc.so.6) #19 0x0000560bc288f1ea n/a (thunar) Stack trace of thread 25009: #0 0x00007f49cd778bb1 __poll (libc.so.6) #1 0x00007f49cd8bb523 n/a (libglib-2.0.so.0) #2 0x00007f49cd8bb8e2 g_main_loop_run (libglib-2.0.so.0) #3 0x00007f49cdeaa348 n/a (libgio-2.0.so.0) #4 0x00007f49cd8e3a2a n/a (libglib-2.0.so.0) #5 0x00007f49cd853a9d start_thread (libpthread.so.0) #6 0x00007f49cd783a43 __clone (libc.so.6) Stack trace of thread 27650: #0 0x00007f49cd77e40d syscall (libc.so.6) #1 0x00007f49cd90252d g_cond_wait_until (libglib-2.0.so.0) #2 0x00007f49cd88d903 n/a (libglib-2.0.so.0) #3 0x00007f49cd8e4436 n/a (libglib-2.0.so.0) #4 0x00007f49cd8e3a2a n/a (libglib-2.0.so.0) #5 0x00007f49cd853a9d start_thread (libpthread.so.0) #6 0x00007f49cd783a43 __clone (libc.so.6) Stack trace of thread 27637: #0 0x00007f49cd77e40d syscall (libc.so.6) #1 0x00007f49cd90252d g_cond_wait_until (libglib-2.0.so.0) #2 0x00007f49cd88d903 n/a (libglib-2.0.so.0) #3 0x00007f49cd8e4436 n/a (libglib-2.0.so.0) #4 0x00007f49cd8e3a2a n/a (libglib-2.0.so.0) #5 0x00007f49cd853a9d start_thread (libpthread.so.0) #6 0x00007f49cd783a43 __clone (libc.so.6) Stack trace of thread 27649: #0 0x00007f49cd88c5c9 g_array_insert_vals (libglib-2.0.so.0) #1 0x00007f49cde2f282 n/a (libgio-2.0.so.0) #2 0x00007f49cde30c79 n/a (libgio-2.0.so.0) #3 0x00007f49cdec0242 n/a (libgio-2.0.so.0) #4 0x00007f49cdec279a n/a (libgio-2.0.so.0) #5 0x00007f49cdebfbe5 n/a (libgio-2.0.so.0) #6 0x00007f49cde2c87b g_file_enumerator_next_file (libgio-2.0.so.0) #7 0x0000560bc28b60c8 n/a (thunar) #8 0x0000560bc28b591b n/a (thunar) #9 0x0000560bc28d709a n/a (thunar) #10 0x00007f49d05b01e7 n/a (libexo-2.so.0) #11 0x00007f49cde3df2e n/a (libgio-2.0.so.0) #12 0x00007f49cde66e39 n/a (libgio-2.0.so.0) #13 0x00007f49cd8e4463 n/a (libglib-2.0.so.0) #14 0x00007f49cd8e3a2a n/a (libglib-2.0.so.0) #15 0x00007f49cd853a9d start_thread (libpthread.so.0) #16 0x00007f49cd783a43 __clone (libc.so.6) Stack trace of thread 27653: #0 0x00007f49cd8ee430 n/a (libglib-2.0.so.0) #1 0x00007f49cd8eefe6 n/a (libglib-2.0.so.0) #2 0x00007f49cd8edf1c g_utf8_collate_key (libglib-2.0.so.0) #3 0x00007f49cd8ee1ee g_utf8_collate_key_for_filename (libglib-2.0.so.0) #4 0x0000560bc28aba7c n/a (thunar) #5 0x0000560bc28ae121 n/a (thunar) #6 0x0000560bc28b6148 n/a (thunar) #7 0x0000560bc28b591b n/a (thunar) #8 0x0000560bc28d709a n/a (thunar) #9 0x00007f49d05b01e7 n/a (libexo-2.so.0) #10 0x00007f49cde3df2e n/a (libgio-2.0.so.0) #11 0x00007f49cde66e39 n/a (libgio-2.0.so.0) #12 0x00007f49cd8e4463 n/a (libglib-2.0.so.0) #13 0x00007f49cd8e3a2a n/a (libglib-2.0.so.0) #14 0x00007f49cd853a9d start_thread (libpthread.so.0) #15 0x00007f49cd783a43 __clone (libc.so.6) Stack trace of thread 25008: #0 0x00007f49cd778bb1 __poll (libc.so.6) #1 0x00007f49cd8bb523 n/a (libglib-2.0.so.0) #2 0x00007f49cd8bb63e g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f49cd8bb692 n/a (libglib-2.0.so.0) #4 0x00007f49cd8e3a2a n/a (libglib-2.0.so.0) #5 0x00007f49cd853a9d start_thread (libpthread.so.0) #6 0x00007f49cd783a43 __clone (libc.so.6) Stack trace of thread 27652: #0 0x00007f49cd77e40d syscall (libc.so.6) #1 0x00007f49cd902411 g_cond_wait (libglib-2.0.so.0) #2 0x00007f49cde3e1cc g_io_scheduler_job_send_to_mainloop (libgio-2.0.so.0) #3 0x00007f49d05b0618 exo_job_emit (libexo-2.so.0) #4 0x0000560bc28b6da2 n/a (thunar) #5 0x0000560bc28b5959 n/a (thunar) #6 0x0000560bc28d709a n/a (thunar) #7 0x00007f49d05b01e7 n/a (libexo-2.so.0) #8 0x00007f49cde3df2e n/a (libgio-2.0.so.0) #9 0x00007f49cde66e39 n/a (libgio-2.0.so.0) #10 0x00007f49cd8e4463 n/a (libglib-2.0.so.0) #11 0x00007f49cd8e3a2a n/a (libglib-2.0.so.0) #12 0x00007f49cd853a9d start_thread (libpthread.so.0) #13 0x00007f49cd783a43 __clone (libc.so.6) Stack trace of thread 27651: #0 0x00007f49cd77e40d syscall (libc.so.6) #1 0x00007f49cd902411 g_cond_wait (libglib-2.0.so.0) #2 0x00007f49cde3e1cc g_io_scheduler_job_send_to_mainloop (libgio-2.0.so.0) #3 0x00007f49d05b0618 exo_job_emit (libexo-2.so.0) #4 0x0000560bc28b6da2 n/a (thunar) #5 0x0000560bc28b5959 n/a (thunar) #6 0x0000560bc28d709a n/a (thunar) #7 0x00007f49d05b01e7 n/a (libexo-2.so.0) #8 0x00007f49cde3df2e n/a (libgio-2.0.so.0) #9 0x00007f49cde66e39 n/a (libgio-2.0.so.0) #10 0x00007f49cd8e4463 n/a (libglib-2.0.so.0) #11 0x00007f49cd8e3a2a n/a (libglib-2.0.so.0) #12 0x00007f49cd853a9d start_thread (libpthread.so.0) #13 0x00007f49cd783a43 __clone (libc.so.6) ```
Usually the *-dev packages only contain the headers of a package. That is only required if you want to build packageB which has a dependency to packageA. Afaik it wIll not help for getting the debug-symbols. To get the debug symbols into your thunar-binary, in Arch(and probably in manjaro), it looks like you need to rebuild thunar with 'makepkg' .... I cannot say much about the details, since I use debian which uses a different approach on that. Best try to follow the related WIki packe and ask the arch/manjaro community, if you get stuck: https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces
thanks a lot for providing me with this info. i will look into this and report back.
Created attachment 7921 PKGBUILD After years using Arch I might be mistaken, but I don't think there are *-dev packages[1] as for Debian/Ubuntu. There are two ways which you can help us: - Easy approach: You can view coredumps with coredumpctl, pay attention to the entries for Thunar and take note of the number of PID column (the most recent occurrence). Then run: coredumpctl dump [PID number] | zip > ~/coredump.zip And send us that file. However, as Alex mentioned, without debug symbols we may not find the part of Thunar's code that is crashing (I can try anyway). - Not so easy approach: More useful to us, but you have to build Thunar from source. It can be a bit tricky, specially for users new to Linux. Since you use Manjaro (Arch under the hood), I have prepared a PKGBUILD (see attachment) which basically automates the whole process. Download it, put in an empty folder (e.g. thunar-build), and run in a terminal from that folder: makepkg -si At the end it will ask to replace the thunar package, confirm and run: pkill -i thunar Now you will be running Thunar with debug enabled, once it crashes you can a meaningful backtrace with: coredumpctl info [PID number] After playing with "thunar-debug", you should restore the package provided by Manjaro with: pacman -S thunar (you may now delete that "thunar-build"). Well, I hope you are not overwhelmed with so many instructions and commands. Let's try the "Easy approach" first. Thanks for reporting and helping us! 1 - https://bugs.archlinux.org/task/38755
thanks a lot for detailed instructions. the easy approach was easy indeed. (`$ coredumpctl dump 25007 | zip > coredump.zip`) however, the coredump file became 22.5 mb so was unable to attach it to this issue: ``` Request Entity Too Large The requested resource /attachment.cgi does not allow request data with POST requests, or the amount of data provided in the request exceeds the capacity limit. ``` anyhow, it can be downloaded here: https://filedn.com/l83EzxKLLIU7GFoqO2C1bgY/180831_thunarBug/ if this doesn't give you sufficient information do let me know. then i will try the "not so easy approach". i don't know if it is of any use, but below is output of `coredumpctl` which gives you an overview of the frequency of the thunar crashes (and other faults that have occurred). ``` [klevstul@silentGamerMjr coredump]$ coredumpctl TIME PID UID GID SIG COREFILE EXE Mon 2018-07-02 20:05:09 CEST 868 1000 1000 11 missing /usr/bin/thunar Mon 2018-07-02 20:05:09 CEST 869 1000 1000 11 missing /usr/bin/thunar Tue 2018-07-03 22:01:18 CEST 8802 1000 1000 11 missing /usr/bin/thunar Thu 2018-07-05 09:55:52 CEST 16881 1000 1000 11 missing /usr/bin/thunar Fri 2018-07-06 17:05:14 CEST 863 1000 1000 11 missing /usr/bin/thunar Fri 2018-07-06 22:55:37 CEST 3938 1000 1000 6 missing /tmp/pamac-build-klevstul/libc++/src/build/> Fri 2018-07-06 22:56:06 CEST 4964 1000 1000 6 missing /tmp/pamac-build-klevstul/libc++/src/build/> Fri 2018-07-06 22:58:52 CEST 10563 1000 1000 6 missing /tmp/pamac-build-klevstul/libc++/src/build/> Sat 2018-07-07 10:33:04 CEST 24843 1000 1000 11 missing /usr/lib/firefox/firefox Sat 2018-07-07 10:33:25 CEST 1343 1000 1000 11 missing /usr/lib/firefox/firefox Sat 2018-07-07 10:33:25 CEST 1353 1000 1000 11 missing /usr/lib/firefox/firefox Sat 2018-07-07 10:33:25 CEST 1341 1000 1000 11 missing /usr/lib/firefox/firefox Sat 2018-07-07 10:33:25 CEST 1207 1000 1000 11 missing /usr/lib/firefox/firefox Sat 2018-07-14 10:31:09 CEST 1350 1000 1000 11 missing /usr/bin/thunar Wed 2018-07-18 19:43:37 CEST 6199 1000 1000 11 missing /usr/bin/thunar Thu 2018-07-19 14:23:20 CEST 9181 1000 1000 6 missing /usr/bin/lmms Tue 2018-07-24 09:56:47 CEST 2471 1000 1000 6 missing /usr/bin/lmms Tue 2018-07-24 10:13:53 CEST 3605 1000 1000 6 missing /usr/bin/lmms Tue 2018-07-24 10:15:29 CEST 3933 1000 1000 6 missing /usr/bin/lmms Tue 2018-07-24 10:20:48 CEST 3970 1000 1000 6 missing /usr/bin/lmms Tue 2018-07-24 10:22:47 CEST 4121 1000 1000 11 missing /usr/bin/lmms Sat 2018-07-28 21:37:59 CEST 875 1000 1000 11 missing /usr/bin/thunar Mon 2018-07-30 08:30:55 CEST 880 1000 1000 11 missing /usr/bin/lmms Mon 2018-08-06 18:57:53 CEST 894 1000 1000 11 missing /usr/bin/thunar Wed 2018-08-08 21:37:55 CEST 7984 1000 1000 11 missing /usr/bin/thunar Thu 2018-08-09 00:31:15 CEST 875 1000 1000 11 missing /usr/bin/thunar Mon 2018-08-13 09:49:54 CEST 1226 1000 1000 11 missing /usr/bin/thunar Thu 2018-08-16 18:27:58 CEST 2535 1000 1000 11 missing /usr/bin/thunar Sat 2018-08-18 16:54:04 CEST 17674 1000 1000 7 missing /usr/lib/tumbler-1/tumblerd Thu 2018-08-23 02:00:01 CEST 29712 0 0 11 missing /usr/bin/crond Fri 2018-08-24 23:12:09 CEST 22744 1000 1000 11 missing /usr/bin/thunar Sun 2018-08-26 16:49:22 CEST 29607 1000 1000 6 missing /usr/share/spotify/spotify Mon 2018-08-27 02:57:02 CEST 6662 1000 1000 11 missing /run/media/klevstul/raid/steam-library/stea> Mon 2018-08-27 02:57:51 CEST 6778 1000 1000 11 missing /run/media/klevstul/raid/steam-library/stea> Mon 2018-08-27 02:58:23 CEST 6880 1000 1000 11 missing /run/media/klevstul/raid/steam-library/stea> Wed 2018-08-29 18:24:16 CEST 25007 1000 1000 11 present /usr/bin/thunar Thu 2018-08-30 02:00:01 CEST 13470 0 0 11 error /usr/bin/crond ```
currently i'm running thunar through gdb. i haven't experienced any crashes yet but i have received some critical errors. no idea if they are related at all. ``` (thunar:1374): thunarx-CRITICAL **: 09:07:06.418: thunarx_menu_provider_get_folder_menu_items: assertion 'thunarx_file_info_is_directory (folder)' failed ```
running `dmesg | grep 'thunar'` i found this: ``` [290311.783736] traps: Thunar[2535] general protection ip:55d7808877a7 sp:7ffd5d5e7f00 error:0 in thunar[55d78084b000+a9000] [998561.656337] Thunar[22744]: segfault at 48 ip 000056232abd8dd0 sp 00007fff46e033c8 error 4 in thunar[56232ab9b000+a9000] [1413286.868756] traps: Thunar[25007] general protection ip:560bc28ab7a7 sp:7fffaed130e0 error:0 in thunar[560bc286f000+a9000] ```
Thanks for the coredump, but no luck so far .. tried to build thunar 1.8.1 from source with debug symbols and run it with your coredump in gdb. > .... > warning: core file may not match specified executable file. > (gdb) backtrace > #0 0x0000560bc28ab7a7 in ?? () > #1 0x0000560bc5c31d30 in ?? () > #2 0x0000560bc5672050 in ?? () > .... If you as well upload your thunar-binary, I could take another try with it, strip off the debug symbols from my own binary and load them into gdb together with your binary (command add-symbol-file) ... no idea if there is a chance that this will work ;) But hey, it will not hurt either ;) For me the binary is located here: "/usr/local/bin/thunar".
Created attachment 7924 thunar binary sorry. forgot the binary. it has now been attached to this issue.
As well no luck, sorry. What I tried: 1. Strip of debug symbols from my own thunar binary: objcopy --only-keep-debug thunar thunar.sym 2. Run gdb with the coredump and your binary gdb thunar coredump 3. Check the hex address to which the symbols need to get attached (.text section) readelf -WS thunar 4. Load the debug symbols in gdb add-symbol-file thunar.sym 0x020010 5. print the backtrace My quess would be that debug symbols only fit to the original binary from which they got stripped .. same architecture, same build flags, etc. Looks like you need to try a different approach .. how about this PKGBUILD provided by Andre Miranda ?
I also tried to load that coredump, but got lots of warnings telling the libraries (gtk, libexo, libxfce4ui...) are of different versions. The backtrace was not useful at all: (gdb) bt full #0 0x0000560bc28ab7a7 in () #1 0x0000560bc28e80e1 in () #2 0x0000560bc28e33bf in () #3 0x00007f49cdb95a4d in () #4 0x0000000000000000 in () So if it's not ask too much, please try the not-so-easy-approach, for sure it will yield a meaningful backtrace. Thanks again
ok. i will try the more advanced approach. however, i have no time today. i will try to do it tomorrow or as quickly as i have a couple of hours available. i will report back. thanks for looking into this.
sry, but have to wait a few days extra before i get to try out the advanced approach. i will report back as soon as i can!
No problem at all, take your time.
a follow up for me. i still haven't gone through with the advanced method for debugging. until now i have just been running thunar via gdb. today i got another crash. this is what was outputted through gdb: ``` [New Thread 0x7fffb37fe700 (LWP 16760)] [New Thread 0x7fffb3fff700 (LWP 16761)] [Thread 0x7fffb37fe700 (LWP 16760) exited] Thread 1 "thunar" received signal SIGSEGV, Segmentation fault. 0x00005555555907a7 in ?? () ``` i will go ahead trying to build thunar from source so i can provide you more useful information. i will report back.
just an update. i am finally on "thunar-debug". with the detailed description above alongside the pkgbuild you provided it worked like a charm. ``` ==> Finished making: thunar-debug 1.8.1-1 (Wed 12 Sep 2018 06:24:10 PM CEST) ==> Installing package thunar-debug with pacman -U... loading packages... resolving dependencies... looking for conflicting packages... :: thunar-debug and thunar are in conflict. Remove thunar? [y/N] y Packages (2) thunar-1.8.1.11.gf5147445-1 [removal] thunar-debug-1.8.1-1 Total Installed Size: 6.89 MiB Net Upgrade Size: 1.28 MiB :: Proceed with installation? [Y/n] Y (1/1) checking keys in keyring [###################################] 100% (1/1) checking package integrity [###################################] 100% (1/1) loading package files [###################################] 100% (1/1) checking for file conflicts [###################################] 100% (2/2) checking available disk space [###################################] 100% :: Processing package changes... (1/1) removing thunar [###################################] 100% (1/1) installing thunar-debug [###################################] 100% Optional dependencies for thunar-debug gvfs: trash support, mounting with udisks, and remote filesystems [installed] xfce4-panel: trash applet [installed] tumbler: for thumbnail previews [installed] thunar-volman: manages removable devices [installed] thunar-archive-plugin-git: create and deflate archives thunar-media-tags-plugin-git: view/edit id3/ogg tags :: Running post-transaction hooks... (1/3) Updating icon theme caches... (2/3) Arming ConditionNeedsUpdate... (3/3) Updating the desktop file MIME type cache... [klevstul@silentGamerMjr thunarBuild]$ pkill -i thunar [klevstul@silentGamerMjr thunarBuild]$ which thunar /usr/bin/thunar ```
another crash and this time gdb provided extra info. do you also need additional files, like the core dump? ``` [Thread 0x7fffcffff700 (LWP 24174) exited] (thunar:3311): GLib-GObject-CRITICAL **: 12:43:24.710: g_object_unref: assertion 'G_IS_OBJECT (object)' failed [New Thread 0x7fffcffff700 (LWP 28143)] Thread 1 "thunar" received signal SIGSEGV, Segmentation fault. 0x00007ffff593f58c in g_type_check_instance_is_a () from /usr/lib/libgobject-2.0.so.0 ```
Yes please, the snippet you posted only tell us that the crash occured in libgobject, but we cannot know from which part of Thunar that function was called. You should be able to get the full backtrace (no need for the core dump yet) with coredumpctl, first get a list of crashes, then find Thunar's crashes, get the backtrace with coredumpctl info <PID>. I guess it should be coredumpctl info 3311
ufortunately `coredumpctl` doesn't show any recent thunar crashes. maybe the reason was due to me running thunar through `gdb`. i've now started thunar the normal way. i will report back, with backtrace, as soon as i experience another crash. ``` [klevstul@silentGamerMjr ~]$ coredumpctl | grep 'thunar' Mon 2018-07-02 20:05:09 CEST 868 1000 1000 11 missing /usr/bin/thunar Mon 2018-07-02 20:05:09 CEST 869 1000 1000 11 missing /usr/bin/thunar Tue 2018-07-03 22:01:18 CEST 8802 1000 1000 11 missing /usr/bin/thunar Thu 2018-07-05 09:55:52 CEST 16881 1000 1000 11 missing /usr/bin/thunar Fri 2018-07-06 17:05:14 CEST 863 1000 1000 11 missing /usr/bin/thunar Sat 2018-07-14 10:31:09 CEST 1350 1000 1000 11 missing /usr/bin/thunar Wed 2018-07-18 19:43:37 CEST 6199 1000 1000 11 missing /usr/bin/thunar Sat 2018-07-28 21:37:59 CEST 875 1000 1000 11 missing /usr/bin/thunar Mon 2018-08-06 18:57:53 CEST 894 1000 1000 11 missing /usr/bin/thunar Wed 2018-08-08 21:37:55 CEST 7984 1000 1000 11 missing /usr/bin/thunar Thu 2018-08-09 00:31:15 CEST 875 1000 1000 11 missing /usr/bin/thunar Mon 2018-08-13 09:49:54 CEST 1226 1000 1000 11 missing /usr/bin/thunar Thu 2018-08-16 18:27:58 CEST 2535 1000 1000 11 missing /usr/bin/thunar Fri 2018-08-24 23:12:09 CEST 22744 1000 1000 11 missing /usr/bin/thunar Wed 2018-08-29 18:24:16 CEST 25007 1000 1000 11 missing /usr/bin/thunar ```
If thunar crashes while you run it through gdb, you can type "bt" or "backtrace" into the gdb prompt to get the backtrace. Or, the other route: In order to get your core dumped, you will need to enable coredumps: https://stackoverflow.com/a/2919398/1599887 E.g. you can put "ulimit -c unlimited" into your ~/.profile. That should enable coredumps automatically for all applications You as well can execute it in the terminal, and than (re)start thunar from the same terminal: ulimit -c unlimited thunar -q;thunar
Created attachment 7983 core dump finally. here you go. see the attached output from the core dump. ``` $ coredumpctl Wed 2018-09-19 10:23:48 CEST 28492 1000 1000 11 present /usr/bin/thunar $ coredumpctl info 28492 > /home/klevstul/Downloads/coreDump.txt ```
Created attachment 7986 coredump and thunar crashed once more today. see attached file. can this have something to do with my raid 10 drive? just one guess...
Created attachment 7987 coredump #3 thunar keeps crashing. third time today. yet another coredump is attached. note: i did disable the raid before the crash, hence there should be no relation.
Created attachment 7988 updated PKGBUILD The provided backtraces do not contain Thunar symbols. I learned that makepkg by default strips those debug symbols. Please rebuild and install Thunar with the updated PKGBUILD (this time I checked the binary with running in gdb). Sorry for the inconvenience.
no worries. i am very pleased for you guys spending time on helping me out here. i have no reinstalled the new version of thunar. when i started it via gdb it also looks like symbols are ok: ``` (gdb) file /usr/bin/thunar Reading symbols from /usr/bin/thunar...done. (gdb) run Starting program: /usr/bin/thunar [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0x7fffeeba6700 (LWP 16106)] [New Thread 0x7fffee3a5700 (LWP 16107)] [New Thread 0x7fffedba4700 (LWP 16108)] [New Thread 0x7fffde4d5700 (LWP 16111)] [New Thread 0x7fffdd76f700 (LWP 16112)] [New Thread 0x7fffdcf6e700 (LWP 16113)] ``` i will report back as soon as i have another coredump ready.
Created attachment 7990 coredump #5 another coredump is attached. does this provide you with some extra info compared with the previous ones? ``` Stack trace of thread 2756: #0 0x00007fcf9e33b58c g_type_check_instance_is_a (libgobject-2.0.so.0) #1 0x00005569f11f0b80 thunar_tree_view_visible_func (thunar) #2 0x00005569f11eb13e thunar_tree_model_item_files_added (thunar) #3 0x00007fcf9e35a3d5 g_closure_invoke (libgobject-2.0.so.0) #4 0x00007fcf9e347195 n/a (libgobject-2.0.so.0) #5 0x00007fcf9e34b01e g_signal_emit_valist (libgobject-2.0.so.0) #6 0x00007fcf9e34ba80 g_signal_emit (libgobject-2.0.so.0) #7 0x00005569f119f128 thunar_folder_monitor (thunar) #8 0x00007fcf9a1791c8 ffi_call_unix64 (libffi.so.6) ... ```
Yay, great, this time the coredump provides useful info ! After some trial and error ( the method mentioned in the coredump looks all fine ), I think I am able to reproduce the bug. However for me thunar does not always crash, but most times only emits some "thunar-CRITICAL " messages into the console and draws a blanc tree-view in all open thunar windows. So it looks like the problem is related to the tree-view and only occurs if more than one thunar window is open. To reproduce I do the following: 1. Open fresh thunar: thunar -q; thunar 2. Switch to tree view if not already visible: View --> SidePane --> Tree 3. Open new window: File --> New Window ( CTRL + N ) 4. Close the new window ( CTRL + Q ) 5. Toggle View-->"show hidden files" ( CTRL + H ) Could you please check if you can reproduce the bug like that as well ? A different bug whicj probably is related: https://bugzilla.xfce.org/show_bug.cgi?id=11903
Here the CRITICAL Message I get: (thunar:12720): thunar-CRITICAL **: thunar_tree_view_visible_func: assertion '(((__extension__ ({ GTypeInstance *__inst = (GTypeInstance*) ((user_data)); GType __t = ((thunar_tree_view_get_type ())); gboolean __r; if (!__inst) __r = (0); else if (__inst->g_class && __inst->g_class->g_type == __t) __r = (!(0)); else __r = g_type_check_instance_is_a (__inst, __t); __r; }))))' failed
sweet. finally, i manage to provide you with some useful info. i can confirm that i always do run two thunar windows at the same time. hence that might be a requirement for the bug to occur. however, i never close one of the windows, as the steps above show. following your steps, at least for the first time, i got a CRITICAL error, but no crash: ``` (thunar:16183): thunar-CRITICAL **: 23:04:34.326: thunar_tree_view_visible_func: assertion '(((__extension__ ({ GTypeInstance *__inst = (GTypeInstance*) ((user_data)); GType __t = ((thunar_tree_view_get_type ())); gboolean __r; if (!__inst) __r = (0); else if (__inst->g_class && __inst->g_class->g_type == __t) __r = (!(0)); else __r = g_type_check_instance_is_a (__inst, __t); __r; }))))' failed ``` will it be useful if i provide you with more coredumps, when i get them? if they show some different info that is. i can just compare the lines at the top.
i can also mention that sometimes the crash has happened while i was copying a lot of data from one location to another. other times it has happened when i was navigating through thunar. i have not noticed any pattern in my behaviour leading to the crashes. however, there might very well be some. as well, maybe there are several reasons for these crashes. if it's not normal to run multiple thunar windows at the same time there might be more bugs. at the above, related bug, shows. i can provide more coredumps when the crashes happen. now i know the drill ((:
and, i always do run tree view. so i guess your assumption is right. bug requirements (if that is an expression): - two (or more?) thunar windows - tree view
Created attachment 7991 core dump #6 another dump. the crash did happen when i tried expanding an entry in the tree view in the left panel when i had another window open.
fyi: i started running only one thunar window, to avoid more crashes. this doesn't help. thunar keeps crashing for me despite only one window running.
@alexxcons I can crash Thunar following your instructions, though the backtrace is not related to the one reported here: #0 0x00005619d1aba3e7 thunar_file_is_gfile_ancestor (thunar) #1 0x00005619d1af5710 thunar_tree_view_visible_func (thunar) #2 0x00005619d1af0fe7 thunar_tree_model_node_traverse_visible (thunar) #3 0x00007f57c35ac97c n/a (libglib-2.0.so.0) #4 0x00007f57c35ac9a1 n/a (libglib-2.0.so.0) #5 0x00007f57c35ac9a1 n/a (libglib-2.0.so.0) #6 0x00007f57c35b3851 g_node_traverse (libglib-2.0.so.0) #7 0x00005619d1af57c6 thunar_tree_view_set_show_hidden (thunar) ... I can also confirm that crash only happens if the tree view is enabled (CTRL+E), but hidden files should not be visible when the first window is created. @frode try to disable the tree view, use the shortcuts view (CTRL+B) for sometime so we can be sure the tree view is the culprit.
@andre will do! i am now running two thunar windows with shortcut view in left pane and no tree view enabled.
Uh, sorry, I should have checked the backtrace before posting. Ok, since it seems to be a different bug, I filed it separately: Bug #14714 ( I wonder if fixing the other one as well fixes this one )
today thunar crashed once more, despite not using the tree view. when i looked at the coredump it looked different. hence, i filed this as a separate bug: https://bugzilla.xfce.org/show_bug.cgi?id=14724
Found a fix for Bug #14714, and I am almost sure that the patch will as well fix your bug. There are two different routes to "thunar_tree_view_visible_func". You took one in your backtrace, I took the other in my backtrace. On both routes a invalid pointer will be used in some circumstances. ( details explained in 14714 ) I would be very happy if you could test the patch, to make sure that it fixes this bug. However this would require you to compile thunar from source ... you want to take a try for it ?
@alexxcons great news. i am more than happy to try out the new fix!
Created attachment 8017 PKGBUILD + patch Here's the PKGBUILD with Alex's patch.
@andre & @alexxcons thanks a lot. i've now successfully built thunar 1.8.2, and running this in tree view. i will report back what i do experience. note: no idea if it means something at all, but i assume you do, so pasting some warnings from the build process below: ``` ~~~~~~~~~~~~~~~ thunar-uca-model.c:211:1: note: in expansion of macro ‘THUNARX_DEFINE_TYPE_WITH_CODE’ THUNARX_DEFINE_TYPE_WITH_CODE (ThunarUcaModel, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../thunarx/thunarx.h:77:5: warning: cast between incompatible function types from ‘void (*)(ThunarUcaModel *)’ {aka ‘void (*)(struct _ThunarUcaModel *)’} to ‘void (*)(GTypeInstance *, void *)’ {aka ‘void (*)(struct _GTypeInstance *, void *)’} [-Wcast-function-type] (GInstanceInitFunc) type_name##_init, \ ^ ../../thunarx/thunarx.h:41:67: note: in expansion of macro ‘THUNARX_DEFINE_TYPE_EXTENDED’ #define THUNARX_DEFINE_TYPE_WITH_CODE(TN, t_n, T_P, _C_) THUNARX_DEFINE_TYPE_EXTENDED (TN, t_n, T_P, 0, _C_) ~~~~~~~~~~~~~~~ thunar-uca-model.c:211:1: note: in expansion of macro ‘THUNARX_DEFINE_TYPE_WITH_CODE’ THUNARX_DEFINE_TYPE_WITH_CODE (ThunarUcaModel, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../thunarx/thunarx.h:90:5: warning: cast between incompatible function types from ‘void (*)(GtkTreeModelIface *)’ {aka ‘void (*)(struct _GtkTreeModelIface *)’} to ‘void (*)(void *, void *)’ [-Wcast-function-type] (GInterfaceInitFunc) iface_init \ ^ ../../thunarx/thunarx.h:82:5: note: in definition of macro ‘THUNARX_DEFINE_TYPE_EXTENDED’ { CODE ; } \ ^~~~ thunar-uca-model.c:211:1: note: in expansion of macro ‘THUNARX_DEFINE_TYPE_WITH_CODE’ THUNARX_DEFINE_TYPE_WITH_CODE (ThunarUcaModel, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ thunar-uca-model.c:214:32: note: in expansion of macro ‘THUNARX_IMPLEMENT_INTERFACE’ THUNARX_IMPLEMENT_INTERFACE (GTK_TYPE_TREE_MODEL, ^~~~~~~~~~~~~~~~~~~~~~~~~~~ CC thunar_uca_la-thunar-uca-plugin.lo ```
just wanted to report back: i have used the new version for a few days now and have not experienced any crashes at all. i'll keep using this new patched version and will report back if i notice any problems.
Sound good to me \o/ Thanks alot for testing ! I'll keeps this bug open for another few days and than close it, if no seg.fault happened for you meanwhile ( ofc you can reopen if the segfault happens later )
one week after i installed the patched version. no problems have re-occurred.
Great ! So I guess we nailed it. Will close it as a dup. of Bug #14714. Thanks again for your effort ! If nevertheless the bug should occur again, feel free to re-open ! *** This bug has been marked as a duplicate of bug 14714 ***