On Wed, Jun 14, 2006 at 05:28:31PM -0700, Barry K. Nathan wrote: > BTW, I actually have a test filesystem here (an e2image from an actual > filesystem I encountered once) that used to cause e2fsck 1.36/1.37 to > segfault. Strangely, more ancient versions (like what ships in Red Hat > 7.2) were able to repair it without segfaulting. In a few days, once > other stuff calms down for me, I need to revisit that and see if the > bug still exists with 1.39. Please try it with 1.39; if it still crashes, let me know --- I treat any filesystem corruptions that causes e2fsck to crash or which e2fsck can't fix in a single pass to be a bug. I'm guessing though that this was probably this bug which was fixed right after 1.38 released (some distributions did have the fix, but it's in the mainline e2fsprogs starting with 1.39): 2005-07-04 Theodore Ts'o <tytso@xxxxxxx> * pass2.c (e2fsck_process_bad_inode): Fixed bug which could cause e2fsck to core dump if a disconnected inode contained an extended attribute. This was actually caused by two bugs. The first bug is that if the inode has been fully fixed up, the code will attempt to remove the inode from the inode_bad_map without checking to see if this bitmap is present. Since it is cleared at the end of pass 2, if e2fsck_process_bad_inode is called in pass 4 (as it is for disconnected inodes), this would result in a core dump. This bug was mostly hidden by a second bug, which caused e2fsck_process_bad_inode() to consider all inodes without an extended attribute to be not fixed. (Addresses Debian Bug: #316736) - Ted - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
