#255 Segfault checking a filesystem

closed-fixed
e2fsck (61)
5
2010-05-17
2010-02-22
No

Hi,

I have a corrupted 7.5TB filesystem that checking it with e2fsck version 1.41.9, ends with a "worst" filesystem where the superblock is filled only with zeros. To try to solve it, I compiled the last version of e2fstools and with that version I receive a segmentation fault.

This is the info about the segmentation faul:

Core was generated by `./e2fsck -C 0 -y -tt /dev/storage/cabina_snapshot2'.
Program terminated with signal 11, Segmentation fault.
#0 0x000000000042d5ef in ext2fs_add_dir_block (dblist=0x1543610, ino=776862480, blk=0, blockcnt=2040523) at dblist.c:177
177 new_entry->blk = blk;

(gdb) bt
#0 0x000000000042d5ef in ext2fs_add_dir_block (dblist=0x1543610, ino=776862480, blk=0, blockcnt=2040523) at dblist.c:177
#1 0x000000000040f9f0 in process_block (fs=0x1537ba0, block_nr=0x154bf70, blockcnt=2100236, ref_block=1488711623, ref_offset=0, priv_data=0x7fff12c8a430)
at pass1.c:2226
#2 0x000000000042a1ce in block_iterate_ind (ind_block=0x154cf78, ref_block=345548583, ref_offset=8, ctx=0x7fff12c8a340) at block.c:94
#3 0x000000000042a580 in block_iterate_dind (dind_block=0x154df74, ref_block=247884314, ref_offset=4, ctx=0x7fff12c8a340) at block.c:171
#4 0x000000000042a904 in block_iterate_tind (tind_block=0x7fff12c8a320, ref_block=0, ref_offset=14, ctx=0x7fff12c8a340) at block.c:250
#5 0x000000000042b291 in ext2fs_block_iterate2 (fs=0x1537ba0, ino=776862480, flags=1, block_buf=0x154bf70 "", func=0x40f604 <process_block>,
priv_data=0x7fff12c8a430) at block.c:482
#6 0x000000000040ef7d in check_blocks (ctx=0x1537840, pctx=0x7fff12c8a4e0, block_buf=0x154bf70 "") at pass1.c:1922
#7 0x000000000040d3be in process_inodes (ctx=0x1537840, block_buf=0x154bf70 "") at pass1.c:1229
#8 0x000000000040ce47 in e2fsck_pass1 (ctx=0x1537840) at pass1.c:1086
#9 0x0000000000408135 in e2fsck_run (ctx=0x1537840) at e2fsck.c:217
#10 0x00000000004073b8 in main (argc=6, argv=0x7fff12c8a9d8) at unix.c:1323

(gdb) info r
rax 0x7fdf4519f010 140596913762320
rbx 0x7fe54519f010 140622683566096
rcx 0xffffffff80000000 -2147483648
rdx 0x0 0
rsi 0x2e4dfb10 776862480
rdi 0x1543610 22296080
rbp 0x7fff12c8a0d0 0x7fff12c8a0d0
rsp 0x7fff12c8a080 0x7fff12c8a080
r8 0x7ff08a2fe760 140671087273824
r9 0x452c7b 4533371
r10 0xfffffff9 4294967289
r11 0x246 582
r12 0x403440 4207680
r13 0x7fff12c8a9d0 140733508528592
r14 0x0 0
r15 0x0 0
rip 0x42d5ef 0x42d5ef <ext2fs_add_dir_block+282>
eflags 0x10282 [ SF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
fctrl 0x37f 895
fstat 0x0 0
ftag 0xffff 65535
fiseg 0x0 0
fioff 0x0 0
foseg 0x0 0
fooff 0x0 0
fop 0x0 0
mxcsr 0x1fa0 [ PE IM DM ZM OM UM PM ]
(gdb)

I think that it is a bug in the e2fsck because the machine is new, the distribution is just installed on the machine (ubuntu karmic), and the kernel doesn't tell me anything else that the segfault.

The core dump is a file of 26GB.

Thanks you very much.

Discussion

  • Andreas Dilger

    Andreas Dilger - 2010-02-25

    It looks like dblist->list == NULL, possibly from failing to realloc() the list earlier. If you still have the core file, can you run it with gdb and "p *dblist" to print out the contents of struct dblist.

    Do you have a very large number of directories in this filesystem that would be causing it to consume a lot of memory?

     
  • Theodore Ts'o

    Theodore Ts'o - 2010-05-17

    Fix checked into the maint branch; will be fixed in e2fsprogs 1.41.12

     
  • Theodore Ts'o

    Theodore Ts'o - 2010-05-17
    • status: open --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks