On 12/13/13, 5:33 PM, Srivatsan Canchivaram wrote: > Hello, > > I found that the segmentation fault occurs in optimized code (-O2). It > does not happen when optimization is turned off. I am not sure what > exactly happened but mke2fs is now able to get past that point. > > The command now fails at a different point: > > ext2fs_mkdir: EXT2 directory corrupted while creating /lost+found > > Tracing from the ext2fs_mkdir() function, I found that the code > returns an error here: > ext2fs_read_dir_block3(): returns EXT2_ET_DIR_CORRUPTED > > Any thoughts or ideas on this issue will be very helpful. I think we need a testcase to be able to help. Does this only happen on MIPS64? Can you gather a core for gdb analysis? -Eric > Thanks, > Sri > > On Tue, Dec 10, 2013 at 5:21 PM, Srivatsan Canchivaram > <crsrivatstechnical@xxxxxxxxx> wrote: >> Hi, >> I have built e2fsprogs-1.42.8 for a MIPS64-based board. The tools were >> generated on an Intel machine with a MIPS64 cross compiler. >> >> MIPS64 board info: >> Linux kernel: 3.4.27 >> Cavium Octeon Plus MIPS64 dual core processor >> 256 MB RAM >> >> The MIPS-based board will have a 2 TB NTFS (or VFAT) formatted >> external USB hard drive connected to it. The goal is to format the 2 >> TB drive from NTFS/ VFAT to EXT4 using the 'mke2fs' program. >> >> 'Mke2fs' results in a segmentation fault when formatting to ext4: >> >> mke2fs -t ext4 /dev/sda1 >> mke2fs 1.42.8 (20-Jun-2013) >> Segmentation fault >> >> As a parallel test, I tried formatting to EXT3 and this worked >> correctly. The issue only seems to occur for EXT4. >> >> Upon further debug, I found the segmentation fault to occur in >> mke2fs.c: end of the should_do_undo() function in the following call: >> io_channel_close(channel); >> >> I tried tracing through the code in the should_do_undo() function. >> The manager->open() call succeeds. >> An issue of note occurs in the following line: >> retval = io_channel_read_blk64(channel, 1, -SUPERBLOCK_SIZE, &super); >> >> The following shows the contents of the 'channel' data structure >> before and after the above function call: >> >> Before call to io_channel_read_blk64() >> ----------------------------------------------------- >> should_do_undo: Channel structure address = 0x1005fd70 >> should_do_undo: magic = 2133571333, name: /dev/sda1, block_size = 1024 >> should_do_undo: refcount = 1, flags = 4, align = 0 >> >> After call to io_channel_read_blk64() >> --------------------------------------------------- >> After Read blk64: Channel structure address = 0x668b1e1a >> Segmentation fault >> >> So, the io_channel_read_blk64() function somehow modifies the >> "channel" structure pointer. Trying to read the structure after the >> call results in a seg fault. >> >> In the io_channel_read_blk64() function, the code takes the following route: >> if (channel->manager->read_blk64) >> return (channel->manager->read_blk64)(channel, block, >> count, data); >> >> If you have any thoughts on this issue or need additional details, >> please let me know. >> >> Thanks, >> >> Sri > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
