Re: xfs_repair segfault

[Eric Sandeen <sandeen@sandeen.net>]

On 3/9/15 11:50 AM, Rui Gomes wrote:
> Program received signal SIGABRT, Aborted.
> 0x00007ffff74275c9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> 56	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> #0  0x00007ffff74275c9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x00007ffff7428cd8 in __GI_abort () at abort.c:90
> #2  0x00007ffff7467db7 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ffff756f561 "*** %s ***: %s terminated\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:196
> #3  0x00007ffff74ff9c7 in __GI___fortify_fail (msg=msg@entry=0x7ffff756f507 "buffer overflow detected") at fortify_fail.c:31
> #4  0x00007ffff74fdb90 in __GI___chk_fail () at chk_fail.c:28
> #5  0x0000000000414ea8 in memmove (__len=18446744073709551615, __src=0x1e562094, __dest=0x7fffffffd8f0) at /usr/include/bits/string3.h:57
> #6  process_sf_dir2 (dirname=0x46b0e2 "", repair=<synthetic pointer>, parent=0x7fffffffdc20, dino_dirty=0x7fffffffdc18, ino_discovery=1, dip=0x1e562000, ino=260256256, mp=0x1e562091) at dir2.c:992

That's here:

                if (junkit)  {
                        memmove(name, sfep->name, namelen); <<<<
                        name[namelen] = '\0';

and the len passed to memmove, 18446744073709551615, is 0xFFFFFFFFFFFFFFFF
or -1 according to gdb.

What are the few lines of xfs_repair output prior to this, i.e. messages
containing "shortform dir"?

If you'd like to create & compress an xfs_metadump & provide it to me offline,
I'll see if that recreates the segfault & look into it further.

Thanks,
-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs