btrfsck seg fault

[kobaz]

btrfs master 2a74d40 tag: v5.6.1

root@Microknoppix:~/download/btrfs-progs# ./btrfsck /dev/sda2 --repair
enabling repair mode
WARNING:

    Do not use --repair unless you are advised to do so by a developer
    or an experienced user, and then only after having accepted that no
    fsck can successfully repair all types of filesystem corruption. Eg.
    some software or hardware bugs can fatally damage a volume.
    The operation will start in 10 seconds.
    Use Ctrl-C to stop it.

10 9 8 7 6 5 4 3 2 1
Starting repair.
Opening filesystem to check...
parent transid verify failed on 425328640 wanted 7763 found 7760
parent transid verify failed on 425328640 wanted 7763 found 7760
parent transid verify failed on 425328640 wanted 7763 found 7760
Ignoring transid failure
Checking filesystem on /dev/sda2
UUID: e7069f30-7630-4949-97c0-170d165ce00b
[1/7] checking root items
Fixed 0 roots.
[2/7] checking extents
ref mismatch on [1365692416 12288] extent item 1, found 0
incorrect local backref count on 1365692416 root 5 owner 12554 offset 0 found 0 wanted 1 back 0x579a70b0
backref disk bytenr does not match extent record, bytenr=1365692416, ref bytenr=0
backpointer mismatch on [1365692416 12288]
owner ref check failed [1365692416 12288]
repair deleting extent record: key [1365692416,168,12288]
Segmentation fault (core dumped)

root@Microknoppix:~/download/btrfs-progs# gdb -c core ./btrfsck
GNU gdb (Debian 8.2.1-2+b1) 8.2.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 "i686-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"...
Reading symbols from ./btrfsck...done.

warning: core file may not match specified executable file.
[New LWP 24840]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `./btrfsck /dev/sda2 --repair'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x5664904d in root_sub_used (size=<error reading variable: Cannot access memory at address 0x44>, root=0x566ecb80) at ctree.h:2141
2141 BTRFS_SETGET_STACK_FUNCS(root_used, struct btrfs_root_item, bytes_used, 64);
(gdb) bt
#0 0x5664904d in root_sub_used (size=<error reading variable: Cannot access memory at address 0x44>, root=0x566ecb80) at ctree.h:2141
#1 balance_level (level=1, path=0x5d38a3c0, root=0x566ecb80, trans=0x5d3601b0) at ctree.c:824
#2 btrfs_search_slot (trans=0x5d3601b0, root=0x566ecb80, key=0xfff6cf6f, p=, ins_len=-1, cow=1) at ctree.c:1214
#3 0x5665011c in lookup_inline_extent_backref (trans=trans@entry=0x5d3601b0, root=root@entry=0x566ecb80, path=path@entry=0x5d38a3c0, ref_ret=0xfff6d088, bytenr=30408704, num_bytes=16384,
parent=0, root_objectid=2, owner=2, offset=0, insert=0) at extent-tree.c:888
#4 0x56650fe3 in lookup_extent_backref (offset=0, owner=2, root_objectid=2, parent=0, num_bytes=16384, bytenr=30408704, ref_ret=0xfff6d088, path=0x5d38a3c0, root=0x566ecb80, trans=0x5d3601b0)
at extent-tree.c:1938
#5 __free_extent (trans=trans@entry=0x5d3601b0, bytenr=, num_bytes=16384, parent=0, root_objectid=2, owner_objectid=2, owner_offset=0, refs_to_drop=1) at extent-tree.c:1938
#6 0x566567f4 in run_delayed_tree_ref (insert_reserved=, extent_op=0x0, node=0x5d37dbe0, fs_info=0x566ec7f0, trans=0x5d3601b0) at extent-tree.c:3758
#7 run_one_delayed_ref (insert_reserved=, extent_op=0x0, node=0x5d37dbe0, fs_info=0x566ec7f0, trans=0x5d3601b0) at extent-tree.c:3778
#8 btrfs_run_delayed_refs (trans=, nr=) at extent-tree.c:3862
#9 0x56663c58 in btrfs_commit_transaction (trans=0x5d3601b0, root=0x566ecb80) at transaction.c:172
#10 0x5661567c in fixup_extent_refs (rec=0x579f2b20, extent_cache=0xfff6d380, info=0x566ec7f0) at check/main.c:7672
#11 check_extent_refs (extent_cache=0xfff6d380, root=0x567c6930) at check/main.c:8043
#12 check_chunks_and_extents (fs_info=0x566ec7f0) at check/main.c:8796
#13 do_check_chunks_and_extents (fs_info=fs_info@entry=0x566ec7f0) at check/main.c:8852
#14 0x56617f88 in cmd_check (cmd=0x566e4000 <cmd_struct_check>, argc=3, argv=0xfff6d914) at check/main.c:10334
#15 0x565e328e in cmd_execute (argv=, argc=, cmd=0x566e4000 <cmd_struct_check>) at cmds/commands.h:125
#16 main (argc=, argv=) at btrfs.c:386

(gdb) p *root
$2 = {node = 0x5d379b80, commit_root = 0x566f7bf0, root_item = {inode = {generation = 1, transid = 0, size = 3, nbytes = 16384, block_group = 0, nlink = 1, uid = 0, gid = 0, mode = 16877,
rdev = 0, flags = 0, sequence = 0, reserved = {0, 0, 0, 0}, atime = {sec = 0, nsec = 0}, ctime = {sec = 0, nsec = 0}, mtime = {sec = 0, nsec = 0}, otime = {sec = 0, nsec = 0}},
generation = 31674, root_dirid = 0, bytenr = 30408704, byte_limit = 0, bytes_used = 18792448, last_snapshot = 0, flags = 0, refs = 1, drop_progress = {objectid = 0, type = 0 '\000',
offset = 0}, drop_level = 0 '\000', level = 2 '\002', generation_v2 = 31674, uuid = '\000' <repeats 15 times>, parent_uuid = '\000' <repeats 15 times>,
received_uuid = '\000' <repeats 15 times>, ctransid = 0, otransid = 0, stransid = 0, rtransid = 0, ctime = {sec = 0, nsec = 0}, otime = {sec = 0, nsec = 0}, stime = {sec = 0, nsec = 0},
rtime = {sec = 0, nsec = 0}, reserved = {0, 0, 0, 0, 0, 0, 0, 0}}, root_key = {objectid = 2, type = 132 '\204', offset = 0}, fs_info = 0x566ec7f0, objectid = 2, last_trans = 31675,
ref_cows = 0, track_dirty = 1, type = 0, last_inode_alloc = 0, unaligned_extent_recs = {next = 0x566ecd78, prev = 0x566ecd78}, dirty_list = {next = 0x566ec91c, prev = 0x566ec91c}, rb_node = {
__rb_parent_color = 0, rb_right = 0x0, rb_left = 0x0}}

Unfortunately, I'm wiping this filesystem today, so I won't have further debugs for you.

Basically what happened was a vmware guest started throwing tremendous IO errors, and automounted to read only.

Upon reboot the filesystem was completely hosed.