'btrfs check' causes segfault
Yestrerday I noticed that one of my drives fails to mount.
Trying to mount the drive the drive on my CachyOS machine fails with "can't read superblock", however btrfs rescue super-recover returns "All supers are valid, no need to recover".
However, running btrfs check fails with the following message:fish: Job 1, 'sudo btrfs check --readonly /de…' terminated by signal SIGSEGV (Address boundary error)
The same thing happens on a Debian Live-ISO (gparted-live-1.8.1-3) and when compiling btrfs-progs from source.
SMART says the drive is ok and I was actively using it before rebooting.
With GDB I got the following backtrace:
#0 calc_extent_flag (extent_cache=extent_cache@entry=0x7fffffffdfd0, buf=buf@entry=0x5555598f1890, ri=ri@entry=0x0, flags=0x7fffffffd9d8) at check/main.c:6346
#1 0x000055555560066d in run_next_block (root=root@entry=0x555555698860, bits=bits@entry=0x555556180040, last=last@entry=0x7fffffffdd78, pending=pending@entry=0x7fffffffdfe0, seen=seen@entry=0x7fffffffdfd8,
reada=reada@entry=0x7fffffffdfe8, nodes=0x7fffffffdff0, extent_cache=0x7fffffffdfd0, chunk_cache=0x7fffffffdfc8, dev_cache=0x7fffffffdfc0, block_group_cache=0x7fffffffe100, dev_extent_cache=0x7fffffffe0a0, ri=0x0, bits_nr=1024)
at check/main.c:6534
#2 0x0000555555602b0a in deal_root_from_list (list=list@entry=0x7fffffffe010, root=root@entry=0x555555698860, bits=bits@entry=0x555556180040, pending=pending@entry=0x7fffffffdfe0, seen=seen@entry=0x7fffffffdfd8,
reada=reada@entry=0x7fffffffdfe8, nodes=0x7fffffffdff0, extent_cache=0x7fffffffdfd0, chunk_cache=0x7fffffffdfc8, dev_cache=0x7fffffffdfc0, block_group_cache=0x7fffffffe100, dev_extent_cache=0x7fffffffe0a0, bits_nr=1024)
at check/main.c:8975
#3 0x0000555555603b41 in check_chunks_and_extents () at check/main.c:9290
#4 0x0000555555608e88 in do_check_chunks_and_extents () at check/main.c:9386
#5 cmd_check (cmd=<optimized out>, argc=<optimized out>, argv=<optimized out>) at check/main.c:11022
#6 0x000055555556ffd6 in cmd_execute (cmd=0x55555568c3c0 <cmd_struct_check>, argc=<optimized out>, argv=<optimized out>) at cmds/commands.h:126
#7 main (argc=<optimized out>, argv=<optimized out>) at btrfs.c:474
Is this something I should report as a bug?
I'm assuming, --repair wouldn't work either because of this bug, but I would like to try and recover my data. (I have a backup, so it's more of a curiosity thing)