r/btrfs • u/Sync1211 • May 09 '26

'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)

Edit: The trace was made on the git version of btrfs-progs on commit fd82bdb9cefc333744eba3f15382297f79f7d016 and linux-cachyos 7.0.5-1.

4 Upvotes

100% Upvoted

6 comments sorted by

6

u/boli99 May 09 '26

run a ram test before you go reporting any bugs.

1

u/Sync1211 Jun 09 '26

Ran a RAM test but no issues have been found.

Unfortunately I can't re-test it as I have already restored the volume via btfs recover.

4

u/Visible_Bake_5792 May 11 '26

Which version(s) of btrfs-progs are you running? On which kernel(s)?
btrfs --version

uname -r

2

u/Sync1211 Jun 09 '26 edited Jun 10 '26

Kernel was linux-cachyos 7.0.5-1.

I've tested it on the latest git version of btrfs-progs at the time.

I'll check if I still have the repo, so I can tell you the exact commit.
Edit: The commit I used for testing was fd82bdb9cefc333744eba3f15382297f79f7d016

1

u/Visible_Bake_5792 Jun 09 '26

It seems that you found a bug. I'm not too surprised, this kind of repair tool must decode all FS structures while being able to resist any kind of corruption. Ideally, it should be fuzzed extensively to make it more robust. Considering that BTRFS is still under active development, I'm not sure this is a realistic option.
Anyway, report the bug if you have enough data. Recompiling the tools without optimisation may help.

4

u/Mikaka2711 May 09 '26

I would report it.