fsck.ext4 crashes with a segfault

Bug #1194234 reported by Forest
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
e2fsprogs (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I was attempting to fix the filesystem on a sata drive when fsck.ext4 crashed.

My command line:

sudo fsck.ext4 -vy /dev/sdd1

Last bit of output from fsck.ext4:

Unconnected directory inode 108960241 (/???)
Connect to /lost+found? yes
Pass 3A: Optimizing directories
Signal (11) SIGSEGV si_code=SI_KERNEL fault addr=(nil)
fsck.ext4[0x426f30]
/lib/x86_64-linux-gnu/libc.so.6(+0x370b0)[0x7f0de29bb0b0]
fsck.ext4[0x4233e2]
/lib/x86_64-linux-gnu/libc.so.6(+0x3aa18)[0x7f0de29bea18]
/lib/x86_64-linux-gnu/libc.so.6(qsort_r+0x223)[0x7f0de29bf5f3]
fsck.ext4(e2fsck_rehash_dir+0x281)[0x4238e1]
fsck.ext4(e2fsck_rehash_directories+0x11e)[0x42457e]
fsck.ext4(e2fsck_pass3+0x616)[0x4197f6]
fsck.ext4(e2fsck_run+0x57)[0x40dd97]
fsck.ext4(main+0xd3c)[0x40a05c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f0de29a5ea5]
fsck.ext4[0x40bc61]

My first attempt to dump the superblock contents failed:

$ sudo tune2fs -l /dev/sdd1
tune2fs 1.42.5 (29-Jul-2012)
tune2fs: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdd1
Couldn't find valid filesystem superblock.

After power cycling the drive, tune2fs worked again:

$ sudo tune2fs -l /dev/sdd1
tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name: slab
Last mounted on: <not available>
Filesystem UUID: 8ce4423d-9bd7-44e3-8096-1dd3f53f9b79
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: unsigned_directory_hash
Default mount options: (none)
Filesystem state: not clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 122101760
Block count: 488378636
Reserved block count: 4883786
Free blocks: 480665217
Free inodes: 122101749
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 907
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Sat Jun 4 00:32:07 2011
Last mount time: n/a
Last write time: Sun Jun 23 20:07:07 2013
Mount count: 0
Maximum mount count: 22
Last checked: Sat Jun 4 00:32:07 2011
Check interval: 15552000 (6 months)
Next check after: Wed Nov 30 23:32:07 2011
Lifetime writes: 30 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 03c936fa-47a9-41dd-ae28-cf6c92b02910
Journal backup: inode blocks

$ uname -a
Linux ocelot 3.8.0-25-generic #37-Ubuntu SMP Thu Jun 6 20:47:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 13.04
Release: 13.04
Codename: raring

The drive is a Seagate Barracuda Green, model ST2000DL003-9VT166

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in e2fsprogs (Ubuntu):
status: New → Confirmed
Revision history for this message
Theodore Ts'o (tytso) wrote :

Was the crash repeatable? It sounds like the drive went out to lunch (since tune2fs -l failed), and the read errors may have caused e2fsck to read bogus information which then caused it to crash. It shouldn't have crashed, of course, but it would be useful to know if that was what happened.

Revision history for this message
Forest (foresto) wrote :

From memory, I'm pretty sure the crashes happened more than once on the same drive and (corrupt) file system, though I don't remember whether the segv was in the same place. Unfortunately, the drive is no longer available to me for testing. I have another one like it, though, and if the same problem appears I'll post details here.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.