Segmentation fault in e4defrag -c

Segmentation fault in e4defrag -c

[Steinar H. Gunderson]

Hi,

I tested e4defrag -c (granted, on a 2.6.30-rc kernel, so it doesn't actually
have the defrag patches, but checking should still work, right?) and it
segfaults with a null pointer deference on certain filesystems. Could you
please take a look?

pannekake:/home/sesse# gdb ./e4defrag
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
(gdb) r -c /dev/mapper/pannekake-home
Starting program: /home/sesse/e4defrag -c /dev/mapper/pannekake-home

Program received signal SIGSEGV, Segmentation fault.
0x00000000004027b9 in get_physical_count (physical_list_head=0x0) at e4defrag.c:1055
1055			if ((ext_list_tmp->data.physical + ext_list_tmp->data.len)
(gdb) bt full
#0  0x00000000004027b9 in get_physical_count (physical_list_head=0x0) at e4defrag.c:1055
	ret = 0
	ext_list_tmp = (struct fiemap_extent_list *) 0x0
#1  0x0000000000402f6c in file_statistic (file=0x60e260 "/home/sesse/Mika - Life In Cartoon Motion/11 - Ring Ring (Bonus Track).mp3", 
    buf=0x7fff33662fd0, flag=0, ftwbuf=0x7fff33667378) at e4defrag.c:1326
	fd = 8
	ret = 0
	now_ext_count = 862335568
	best_ext_count = 32767
	physical_ext_count = 862352208
	i = 32767
	j = 32
	ratio = 0
	blk_count = 0
	msg_buffer = "(", '\0' <repeats 15 times>, "\030!f3ÿ\177\000\000\000\000\000\000f\000\000\000À\022a\000\000\000\000\000/home/se/home/lo\a\000\000\000\000\000\000\000\2200f3ÿ\177\000\000\035\000\000\000\000\000\000\000P2f3ÿ\177\000\000\004\000\000\000\000\000\000\000à0f3ÿ\177\000\000Ñ,@\000\000\000\000\000P2f3ÿ\177\000\000VêÜæb\177\000\000Psf3ÿ\177\000\000C'@\000\000\000\000\000\020Ð`\000\000\000\000\000ày\nçb\177\000\000xsf3ÿ\177\000\000\f\000\000\000\001\000\000\000@1f3ÿ\177\000\000`â`", '\0' <repeats 21 times>, "Psf3ÿ\177\000\000"...
	physical_list_head = (struct fiemap_extent_list *) 0x0
	logical_list_head = (struct fiemap_extent_list *) 0x0
#2  0x00007f62e6e1d73a in ?? () from /lib/libc.so.6
No symbol table info available.
#3  0x00007f62e6e1da85 in ?? () from /lib/libc.so.6
No symbol table info available.
#4  0x00007f62e6e1d67e in ?? () from /lib/libc.so.6
No symbol table info available.
#5  0x00007f62e6e1da85 in ?? () from /lib/libc.so.6
No symbol table info available.
#6  0x00007f62e6e1d67e in ?? () from /lib/libc.so.6
No symbol table info available.
#7  0x00007f62e6e1da85 in ?? () from /lib/libc.so.6
No symbol table info available.
#8  0x00007f62e6e1e2cb in ?? () from /lib/libc.so.6
No symbol table info available.
#9  0x0000000000404a67 in main (argc=3, argv=0x7fff336689e8) at e4defrag.c:2022
	mount_dir_len = 32767
	opt = -1
	i = 2
	j = 0
	flags = 3
	arg_type = 0
	success_flag = 0
	dir_name = "/home", '\0' <repeats 4091 times>
	buf = {st_dev = 64787, st_ino = 2, st_nlink = 33, st_mode = 16877, st_uid = 0, st_gid = 0, pad0 = 0, st_rdev = 0, st_size = 4096, 
  st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1245891895, tv_nsec = 968453897}, st_mtim = {tv_sec = 1245401183, 
    tv_nsec = 304453887}, st_ctim = {tv_sec = 1245401183, tv_nsec = 304453887}, __unused = {0, 0, 0}}
	sb = {s_inodes_count = 2621440, s_blocks_count_lo = 10485760, s_r_blocks_count_lo = 524224, s_free_blocks_count_lo = 3310667, 
  s_free_inodes_count = 2377762, s_first_data_block = 0, s_log_block_size = 2, s_obso_log_frag_size = 2, s_blocks_per_group = 32768, 
  s_obso_frags_per_group = 32768, s_inodes_per_group = 8192, s_mtime = 1243121832, s_wtime = 1243121832, s_mnt_count = 11, 
  s_max_mnt_count = 38, s_magic = 61267, s_state = 1, s_errors = 1, s_minor_rev_level = 0, s_lastcheck = 1239019329, 
  s_checkinterval = 15552000, s_creator_os = 0, s_rev_level = 1, s_def_resuid = 0, s_def_resgid = 0, s_first_ino = 11, 
  s_inode_size = 256, s_block_group_nr = 0, s_feature_compat = 60, s_feature_incompat = 582, s_feature_ro_compat = 123, 
  s_uuid = "À{Ó;{rM*\227±Ã\22742\v2", s_volume_name = '\0' <repeats 15 times>, s_last_mounted = '\0' <repeats 63 times>, 
  s_algorithm_usage_bitmap = 0, s_prealloc_blocks = 0 '\0', s_prealloc_dir_blocks = 0 '\0', s_reserved_gdt_blocks = 1021, 
  s_journal_uuid = '\0' <repeats 15 times>, s_journal_inum = 8, s_journal_dev = 0, s_last_orphan = 655808, s_hash_seed = {3246912957, 
    3041674718, 1885689521, 1976377087}, s_def_hash_version = 2 '\002', s_reserved_char_pad = 1 '\001', s_desc_size = 0, 
  s_default_mount_opts = 0, s_first_meta_bg = 0, s_mkfs_time = 1219499056, s_jnl_blocks = {9255, 9256, 9257, 9258, 9259, 9260, 9261, 
    9262, 9263, 9264, 9265, 9266, 9267, 10292, 0, 0, 134217728}, s_blocks_count_hi = 0, s_r_blocks_count_hi = 0, 
  s_free_blocks_count_hi = 0, s_min_extra_isize = 28, s_want_extra_isize = 28, s_flags = 1, s_raid_stride = 0, s_mmp_interval = 0, 
  s_mmp_block = 0, s_raid_stripe_width = 0, s_log_groups_per_flex = 4 '\004', s_reserved_char_pad2 = 0 '\0', s_reserved_pad = 0, 
  s_reserved = {15648, 0 <repeats 161 times>}}

/* Steinar */
-- 
Homepage: http://www.sesse.net/
--
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

Re: Segmentation fault in e4defrag -c

[Kazuya Mio]

Hi Steinar,

Thanks for testing defrag.

e4defrag -c works fine in the case without defrag patch.
I cannot reproduce this problem, so I think this problem occurred in unusual 
cases (e.g. i_size is not zeroed but it has no extent)


To solve this problem, could you send me the following information?
1. mount option of /home/sesse
2. filefrag -v "/home/sesse/Mika - Life In Cartoon Motion/11 - Ring Ring (Bonus 
Track).mp3"
3. stat "/home/sesse/Mika - Life In Cartoon Motion/11 - Ring Ring (Bonus Track).mp3"

Does this problem occur at all times?

Regards,

Kazuya Mio

Re: Segmentation fault in e4defrag -c

[Steinar H. Gunderson]

On Fri, Jun 26, 2009 at 05:32:48PM +0900, Kazuya Mio wrote:
> e4defrag -c works fine in the case without defrag patch.

I tried 2.6.31-rc1 now (which should have the defrag patch, right?).
There's no change -- and it still cannot actually defrag for some reason.

> To solve this problem, could you send me the following information?
> 1. mount option of /home/sesse

/dev/mapper/pannekake-home on /home type ext4 (rw,errors=remount-ro)

> 2. filefrag -v "/home/sesse/Mika - Life In Cartoon Motion/11 - Ring
> Ring (Bonus Track).mp3"

pannekake:~# filefrag -v "/home/sesse/Mika - Life In Cartoon Motion/11 - Ring Ring (Bonus Track).mp3" 
Checking /home/sesse/Mika - Life In Cartoon Motion/11 - Ring Ring (Bonus Track).mp3
Filesystem type is: ef53
Filesystem cylinder groups is approximately 315
File is stored in extents format
Blocksize of file /home/sesse/Mika - Life In Cartoon Motion/11 - Ring Ring (Bonus Track).mp3 is 4096
File size of /home/sesse/Mika - Life In Cartoon Motion/11 - Ring Ring (Bonus Track).mp3 is 4050385 (989 blocks)
First block: 0
Last block: 0
/home/sesse/Mika - Life In Cartoon Motion/11 - Ring Ring (Bonus Track).mp3: 1 extent found

> 3. stat "/home/sesse/Mika - Life In Cartoon Motion/11 - Ring Ring (Bonus Track).mp3"

pannekake:~# stat "/home/sesse/Mika - Life In Cartoon Motion/11 - Ring Ring (Bonus Track).mp3" 
  File: `/home/sesse/Mika - Life In Cartoon Motion/11 - Ring Ring (Bonus Track).mp3'
  Size: 4050385   	Blocks: 0          IO Block: 4096   regular file
Device: fd12h/64786d	Inode: 688755      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   sesse)   Gid: ( 1000/   sesse)
Access: 2009-05-30 03:08:38.724454316 +0200
Modify: 2008-09-01 20:38:26.135589449 +0200
Change: 2008-09-01 20:38:26.135589449 +0200

> Does this problem occur at all times?

Yes, it's 100% consistent on that file.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: Segmentation fault in e4defrag -c

[Akira Fujita]

Hi,

Steinar H. Gunderson wrote:
>> 3. stat "/home/sesse/Mika - Life In Cartoon Motion/11 - Ring Ring (Bonus Track).mp3"
> 
> pannekake:~# stat "/home/sesse/Mika - Life In Cartoon Motion/11 - Ring Ring (Bonus Track).mp3" 
>   File: `/home/sesse/Mika - Life In Cartoon Motion/11 - Ring Ring (Bonus Track).mp3'
>   Size: 4050385   	Blocks: 0          IO Block: 4096   regular file
> Device: fd12h/64786d	Inode: 688755      Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1000/   sesse)   Gid: ( 1000/   sesse)
> Access: 2009-05-30 03:08:38.724454316 +0200
> Modify: 2008-09-01 20:38:26.135589449 +0200
> Change: 2008-09-01 20:38:26.135589449 +0200

Thank you for information.

File size is "4050385" but Blocks is "0"
probably means blocks are not allocated yet or file is *corrupted*.
Is your mp3 file available?

Anyway, with this patch, 0 blocks file is skipped,
therefore the segmentation fault you had will not happen.

Thanks and Regards,
Akira Fujita

Signed-off-by Akira Fujita <a-fujita@rs.jp.nec.com>
---
 online-defrag-cmd |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
--- online-defrag-cmd	2009-06-29 13:07:16.000000000 +0900
+++ online-defrag-cmd-20090629	2009-06-29 13:07:41.000000000 +0900
@@ -1303,6 +1303,15 @@ int file_statistic(const char *file, con
 		return 0;
 	}

+	/* Has no blocks */
+	if (buf->st_blocks == 0) {
+		if (mode_flag & DETAIL) {
+			PRINT_FILE_NAME(file);
+			STATISTIC_ERR_MSG("File has no blocks");
+		}
+		return 0;
+	}
+
 	fd = open64(file, O_RDONLY);
 	if (fd < 0) {
 		if (mode_flag & DETAIL) {
@@ -1624,6 +1633,15 @@ int file_defrag(const char *file, const
 		return 0;
 	}

+	/* Has no blocks */
+	if (buf->st_blocks == 0) {
+		if (mode_flag & DETAIL) {
+			PRINT_FILE_NAME(file);
+			STATISTIC_ERR_MSG("File has no blocks");
+		}
+		return 0;
+	}
+
 	fd = open64(file, O_RDONLY);
 	if (fd < 0) {
 		if (mode_flag & DETAIL) {

Re: Segmentation fault in e4defrag -c

[Andreas Dilger]

On Jun 29, 2009  15:03 +0900, Akira Fujita wrote:
> >   Size: 4050385   	Blocks: 0          IO Block: 4096   regular file
> > Device: fd12h/64786d	Inode: 688755      Links: 1
> > Access: (0644/-rw-r--r--)  Uid: ( 1000/   sesse)   Gid: ( 1000/   sesse)
> > Access: 2009-05-30 03:08:38.724454316 +0200
> > Modify: 2008-09-01 20:38:26.135589449 +0200
> > Change: 2008-09-01 20:38:26.135589449 +0200
> 
> File size is "4050385" but Blocks is "0"
> probably means blocks are not allocated yet or file is *corrupted*.
> Is your mp3 file available?

Well, this is a sparse file for some reason (e.g. failed mp3 p2p download).

> Anyway, with this patch, 0 blocks file is skipped,
> therefore the segmentation fault you had will not happen.

Is it possible that the code has not been tested with sparse files?
In that case, the check for size == 0 is only going to catch a single
case of problem, and not handle general sparse files.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

Re: Segmentation fault in e4defrag -c

[Akira Fujita]

Hi,
Andreas Dilger wrote:
> On Jun 29, 2009  15:03 +0900, Akira Fujita wrote:
>>>   Size: 4050385   	Blocks: 0          IO Block: 4096   regular file
>>> Device: fd12h/64786d	Inode: 688755      Links: 1
>>> Access: (0644/-rw-r--r--)  Uid: ( 1000/   sesse)   Gid: ( 1000/   sesse)
>>> Access: 2009-05-30 03:08:38.724454316 +0200
>>> Modify: 2008-09-01 20:38:26.135589449 +0200
>>> Change: 2008-09-01 20:38:26.135589449 +0200
>> File size is "4050385" but Blocks is "0"
>> probably means blocks are not allocated yet or file is *corrupted*.
>> Is your mp3 file available?
> 
> Well, this is a sparse file for some reason (e.g. failed mp3 p2p download).
> 

Ah, may be so.

>> Anyway, with this patch, 0 blocks file is skipped,
>> therefore the segmentation fault you had will not happen.
> 
> Is it possible that the code has not been tested with sparse files?
> In that case, the check for size == 0 is only going to catch a single
> case of problem, and not handle general sparse files.
> 

I have tested files that have sparse blocks
(e.g. files that have sparse blocks in its beginning,
middle and those combinations) and got fine results.
Unfortunately, like this case, only 0 blocks file (all sparse blocks)
has not been tested yet.

But the kernel space (EXT4_IOC_MOVE_EXTENT) does not have this kind of issue.
Because there is a check of whether the extents of orig_inode
that ext4_ext_find_extent() gets is NULL.
If extents is NULL or ext4_ext_find_extent() fails,
ext4_move_extents() returns an error value (e.g. EINVAL) to the user space.

Regards,
Akira Fujita