segmentation fault when deleting directory

[symphorien]

Steps to reproduce:

• start btdu /
• press s
• navigate to a directory
• press d, confirm with shift y

segmentation fault:

Process 172272 stopped
* thread #2, name = 'btdu', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x140)
    frame #0: 0x0000aaaaaaaf31e4 btdu`_D2ae3sys4file__T7listDirS4btdu2ui8deletion7Deleter10threadFuncMFZ17__lambda_L127_C13VE3std8typecons__T4FlagVAyaa11_696e636c756465526f6f74ZQBki1Z5Entry__T7recurseTbTPSQFl5paths11BrowserPathTPbZQBnMFbKQBjQnZ20__dgliteral_L275_C13MFNaNiNfZAxa + 100
btdu`_D2ae3sys4file__T7listDirS4btdu2ui8deletion7Deleter10threadFuncMFZ17__lambda_L127_C13VE3std8typecons__T4FlagVAyaa11_696e636c756465526f6f74ZQBki1Z5Entry__T7recurseTbTPSQFl5paths11BrowserPathTPbZQBnMFbKQBjQnZ20__dgliteral_L275_C13MFNaNiNfZAxa:
->  0xaaaaaaaf31e4 <+100>: ldr    x21, [x23, #0x140]
    0xaaaaaaaf31e8 <+104>: cbnz   x21, 0xaaaaaaaf31b4 ; <+52>
    0xaaaaaaaf31ec <+108>: b      0xaaaaaaaf3208 ; <+136>
    0xaaaaaaaf31f0 <+112>: mov    x20, xzr
(lldb) bt
* thread #2, name = 'btdu', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x140)
  * frame #0: 0x0000aaaaaaaf31e4 btdu`_D2ae3sys4file__T7listDirS4btdu2ui8deletion7Deleter10threadFuncMFZ17__lambda_L127_C13VE3std8typecons__T4FlagVAyaa11_696e636c756465526f6f74ZQBki1Z5Entry__T7recurseTbTPSQFl5paths11BrowserPathTPbZQBnMFbKQBjQnZ20__dgliteral_L275_C13MFNaNiNfZAxa + 100
    frame #1: 0x0000aaaaaaaf30e0 btdu`_D4btdu2ui8deletion7Deleter10threadFuncMFZ__T17__lambda_L127_C13TPS2ae3sys4file__T7listDirSQDlQDjQDjQDdQCyMFZQCmVE3std8typecons__T4FlagVAyaa11_696e636c756465526f6f74ZQBki1Z5EntryZQFeMFQEpbPSQHg5paths11BrowserPathPbZv + 1976
    frame #2: 0x0000aaaaaaaf24a0 btdu`_D2ae3sys4file__T7listDirS4btdu2ui8deletion7Deleter10threadFuncMFZ17__lambda_L127_C13VE3std8typecons__T4FlagVAyaa11_696e636c756465526f6f74ZQBki1Z__TQFbTQBrTbTPSQFe5paths11BrowserPathTnZQGmMFQDdbQBkQoZv + 500
    frame #3: 0x0000aaaaaaaf2224 btdu`_D4btdu2ui8deletion7Deleter10threadFuncMFZv + 148
    frame #4: 0x0000aaaaaacc2a94 btdu`thread_entryPoint + 88
    frame #5: 0x0000fffff7c43380 libc.so.6`start_thread + 1016
    frame #6: 0x0000fffff7cb2c1c libc.so.6`thread_start + 12
(lldb) 

unfortunately, I have debug symbols in a debuginfod server but they are not available because:

• running gdb btdu just eats memory until it crashes

$  ../../gdb/utils.c:671: internal-error: virtual memory exhausted.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x60e20094b6f0 _Z22gdb_internal_backtracev
0x60e200ea0494 _ZL17internal_vproblemP16internal_problemPKciS2_P13__va_list_tag
0x60e200ea08aa _Z15internal_verrorPKciS0_P13__va_list_tag
0x60e201435810 _Z18internal_error_locPKciS0_z
0x60e200e9b537 _Z14malloc_failurel
0x60e20089dae9 xrealloc
0x60e201422d39 string_need
0x60e201424d3a dlang_parse_template
0x60e201425159 dlang_parse_qualified
0x60e2014249b0 dlang_parse_template
0x60e201425159 dlang_parse_qualified
0x60e201424e11 dlang_parse_template
0x60e201425159 dlang_parse_qualified
0x60e2014249b0 dlang_parse_template
0x60e201425159 dlang_parse_qualified
0x60e2014249b0 dlang_parse_template
0x60e201425159 dlang_parse_qualified
0x60e2014249b0 dlang_parse_template
0x60e201425159 dlang_parse_qualified
0x60e2014249b0 dlang_parse_template
0x60e201425159 dlang_parse_qualified
0x60e201424e11 dlang_parse_template
0x60e201425159 dlang_parse_qualified
0x60e2014249b0 dlang_parse_template
0x60e201425159 dlang_parse_qualified
0x60e201424e11 dlang_parse_template
0x60e201425159 dlang_parse_qualified
0x60e2014249b0 dlang_parse_template
0x60e201425159 dlang_parse_qualified
0x60e2014249b0 dlang_parse_template
0x60e201425159 dlang_parse_qualified
0x60e201425476 dlang_parse_mangle
0x60e201425c7e dlang_demangle
0x60e20101a67a bfd_demangle
0x60e2009dd1e6 _Z12gdb_demanglePKci
0x60e200974676 _ZNK14cplus_language23sniff_from_mangled_nameEPKcPSt10unique_ptrIcN3gdb13xfree_deleterIcEEE
0x60e200dff106 _Z26symbol_find_demangled_nameP19general_symbol_infoPKc
0x60e200bf2c54 _ZZN21minimal_symbol_reader7installEvENKUlP14minimal_symbolS1_E_clES1_S1_
0x60e200a0d004 _ZNSt17_Function_handlerIFSt10unique_ptrINSt13__future_base12_Result_baseENS2_8_DeleterEEvENS1_12_Task_setterIS0_INS1_7_ResultIvEES3_EZNS1_11_Task_stateISt8functionIFvvEESaIiESC_E6_M_runEvEUlvE_vEEE9_M_invokeERKSt9_Any_data
0x60e200a0d1cd _ZNSt13__future_base13_State_baseV29_M_do_setEPSt8functionIFSt10unique_ptrINS_12_Result_baseENS3_8_DeleterEEvEEPb
0x7bc754aa346b __pthread_once_slow.isra.0
0x7bc754aa34f0 ___pthread_once
0x60e201442f55 _ZN3gdb11thread_pool15thread_functionEv
0x7bc754ef2fa3 execute_native_thread_routine
0x7bc754a9dd52 start_thread
0x7bc754b2563b __clone3
0xffffffffffffffff ???
---------------------

This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

• I ran this inside lldb but lldb does not support debuginfod afaict

If that matters, I had this issue on Nixos 25.11 aarch64-linux, both with btdu 0.6.0 and 0.7.2 (the version on unstable).