Segfault After Downloads

Version information

• Thunar: 4.20.1

• Kernel: Linux 6.12.8-zen1-1-zen
• WM: Hyprland 0.46.2

Steps to reproduce

I'm not really sure about this one as it seems to happen when downloading files. It isn't every time that it does this, but rather it usually happens after around 5-30 minutes of active use.

Current behavior

Crashes on completion.

Expected outcome

Should not crash.

Backtrace

Jan 12 10:35:16 SaltyPC kernel: pool-thunar[344036]: segfault at ffffffff00100016 ip 000072372340ddce sp 000072370fffe960 error 5 in libgobject-2.0.so.0.8200.4[37dce,7237233e2000+38000] likely on CPU 0 (core 0, socket 0)
Jan 12 10:35:16 SaltyPC kernel: Code: 00 00 48 8b 07 48 89 f9 48 3d fc 03 00 00 76 4c 48 83 e0 fc 48 81 fe fc 03 00 00 0f 86 43 01 00 00 48 83 e6 fc ba 01 00 00 00 <f6> 40 16 10 74 04 84 d2 75 53 48 8d 15 e1 45 01 00 be 08 00 00 00
Jan 12 10:35:16 SaltyPC systemd-coredump[348605]: Process 258822 (thunar) of user 60037 terminated abnormally with signal 11/SEGV, processing...
Jan 12 10:35:16 SaltyPC systemd[1]: Started Process Core Dump (PID 348605/UID 0).
Jan 12 10:35:17 SaltyPC systemd-coredump[348607]: [🡕] Process 258822 (thunar) of user 60037 dumped core.

                                                  Stack trace of thread 344036:
                                                  #0  0x000072372340ddce g_type_interface_peek (libgobject-2.0.so.0 + 0x37dce)
                                                  #1  0x0000723723487eec g_file_query_info (libgio-2.0.so.0 + 0x51eec)
                                                  #2  0x000060924837d996 n/a (n/a + 0x0)
                                                  #3  0x0000609248383c8e n/a (n/a + 0x0)
                                                  #4  0x00006092483ac792 n/a (n/a + 0x0)
                                                  #5  0x000072372416f45e n/a (libexo-2.so.0 + 0xf45e)
                                                  #6  0x00007237234ae59a n/a (libgio-2.0.so.0 + 0x7859a)
                                                  #7  0x00007237234e3936 n/a (libgio-2.0.so.0 + 0xad936)
                                                  #8  0x000072372331bca3 n/a (libglib-2.0.so.0 + 0x95ca3)
                                                  #9  0x0000723723318be6 n/a (libglib-2.0.so.0 + 0x92be6)
                                                  #10 0x000072372312939d n/a (libc.so.6 + 0x9439d)
                                                  #11 0x00007237231ae49c n/a (libc.so.6 + 0x11949c)

                                                  Stack trace of thread 258822:
                                                  #0  0x0000723723213de0 n/a (libc.so.6 + 0x17ede0)
                                                  #1  0x000060924837e211 n/a (n/a + 0x0)
                                                  #2  0x00006092483d6f96 n/a (n/a + 0x0)
                                                  #3  0x000060924837b172 n/a (n/a + 0x0)
                                                  #4  0x000060924837bc2c n/a (n/a + 0x0)
                                                  #5  0x00007237234a7a18 n/a (libgio-2.0.so.0 + 0x71a18)
                                                  #6  0x0000723723408e1c n/a (libgobject-2.0.so.0 + 0x32e1c)
                                                  #7  0x0000723723408f32 g_signal_emit_valist (libgobject-2.0.so.0 + 0x32f32)
                                                  #8  0x0000723723408ff4 g_signal_emit (libgobject-2.0.so.0 + 0x32ff4)
                                                  #9  0x0000723723571595 n/a (libgio-2.0.so.0 + 0x13b595)
                                                  #10 0x00007237232e3559 n/a (libglib-2.0.so.0 + 0x5d559)
                                                  #11 0x0000723723346257 n/a (libglib-2.0.so.0 + 0xc0257)
                                                  #12 0x00007237232e2a55 g_main_context_iteration (libglib-2.0.so.0 + 0x5ca55)
                                                  #13 0x0000723723514cb6 g_application_run (libgio-2.0.so.0 + 0xdecb6)
                                                  #14 0x00006092483551a1 n/a (n/a + 0x0)
                                                  #15 0x00007237230bae08 n/a (libc.so.6 + 0x25e08)
                                                  #16 0x00007237230baecc __libc_start_main (libc.so.6 + 0x25ecc)
                                                  #17 0x00006092483552d5 n/a (n/a + 0x0)
                                                  ELF object binary architecture: AMD x86-64
Jan 12 10:35:17 SaltyPC systemd[1]: systemd-coredump@7-348605-0.service: Deactivated successfully.
Jan 12 10:35:17 SaltyPC systemd[1]: systemd-coredump@7-348605-0.service: Consumed 264ms CPU time, 184M memory peak.

changed title from Segfault After File Transfers to Segfault After Downloads

changed the description

Thank you for reporting!

To further debug this, more details will be required:

• Your backtrace misses thunar debug symbols to be usefull. Could you please install them? (Here more info)

added 1. Crash / Freeze 3. Need Info 5. File Operations labels

Possibly related to #1535 (closed)

The file transfer settings are as follows:

• Transfer files in parallel: Local Files Only (Idle Devices)
• Use intermediate file on copy: Never
• Verify file content on Copy: Never

Here is the full backtrace: backtrace.log

Thank you for the trace!

It's a strange trace ... feels like only each second method involved is listed

So in the end g_file_query_info (or g_local_file_query_info, which probably is a subroutine) seems to fail because the variable local->filename is uninitialized.

I am not completely sure about the cause ... feels like we are calling g_file_query_info with a corrupt g_file. I guess during download, temporary files are created by the browser, which are renamed, once the download finishes, causing a swap of the g_file inside the thunar_file_replace_file. If that g_file is in use by the content type loading thread at the same time, that could cause a raise condition.

Will try to provide a patch for it.

I have a potential fix for it in !581 (merged) . If you are able to build thunar from source, it would be great if you could give it a try, before I apply it.

Did the same for _thunar_job_load_statusbar_text, which can suffer from the same issue.

mentioned in merge request !581 (merged)

mentioned in commit 867d5067

mentioned in commit 0cbbe31d

changed milestone to %4.20.2

Hopefully fixed by !581 (merged), to be released in 4.20.0. If it still occurs in that version, please reopen.

closed

mentioned in commit e1ba0aaf

mentioned in commit c0896df6

mentioned in merge request !583 (merged)

mentioned in commit 39d0e29a

mentioned in commit a071742e