Re: Segmentation fault in mke2fs

[Eric Sandeen <sandeen@redhat.com>]

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@gmail.com> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>