All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Browning <db@kavod.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: [solved] xfsrestore segfault (was: Re: xfsdump segfault)
Date: Sat, 16 Feb 2013 19:47:13 -0800	[thread overview]
Message-ID: <201302161947.13836.db@kavod.com> (raw)
In-Reply-To: <201302161606.02693.db@kavod.com>

On Saturday 16 February 2013 4:06:02 pm Daniel Browning wrote:
> So it appears that a socket is causing the problem. What should I
> try next?

Turns out it was already fixed in git HEAD, so take this email as
my personal vote for releasing 3.1.3 sooner rather than later,
for whatever that's worth. :)

commit 59ad060e8f8c39406838c37360efb5f6c09a9041
Author: Alex Elder <elder@inktank.com>
Date:   Thu Dec 27 08:10:14 2012 -0600

    xfsdump: fix format string in restore_spec()
    
    Nigel Tamplin reported getting a seg fault in xfsrestore when a path
    name was too long.  He correctly diagnosed that the problem was due
    to an extra "%s" format specifier in the format value passed to a
    call to mlog().  This patch corrects that.
    
    Signed-off-by: Alex Elder <elder@inktank.com>
    Reported-by: Nigel Tamplin <ntamplin@codefaber.co.uk>
    Tested-by: Nigel Tamplin <ntamplin@codefaber.co.uk>
    Signed-off-by: Ben Myers <bpm@sgi.com>

diff --git a/restore/content.c b/restore/content.c
index edd00ed..54d933c 100644
--- a/restore/content.c
+++ b/restore/content.c
@@ -7796,7 +7796,7 @@ restore_spec( filehdr_t *fhdrp, rv_t *rvp, char *path )
            if ( strlen( path ) >= sizeof( addr.sun_path )) {
                mlog( MLOG_VERBOSE | MLOG_WARNING, _(
                      "pathname too long for bind of "
-                     "%s ino %llu %s: %s: discarding\n"),
+                     "%s ino %llu %s: discarding\n"),
                      printstr,
                      fhdrp->fh_stat.bs_ino,
                      path );


Dave Chinner helped me further on IRC and suggested gdb. When I
got the stacktrace, Nathan Scott on the channel used it to find
the problem area and the commit that fixed it. I applied just
that one commit to 3.1.2, recompiled, and confirmed that it is
fixed.

For the sake of completeness I'll post the stacktrace anyway
(with a few ellipsis for anonymization).

Thanks again everyone,
--
DB

/sbin/xfsrestore: truncating secondary/[...]/mod_interchange.html from 0 to 22744
/sbin/xfsrestore: drive_simple read( want 32 )
/sbin/xfsrestore: drive_simple return_read_buf( returning 32 )
/sbin/xfsrestore: xlate_extenthdr
/sbin/xfsrestore: read extent hdr size 23040 offset 0 type 4 flags 00000001
/sbin/xfsrestore: read extent hdr type DATA offset 0 sz 23040 flags 1
/sbin/xfsrestore: drive_simple read( want 23040 )
/sbin/xfsrestore: drive_simple return_read_buf( returning 23040 )
/sbin/xfsrestore: drive_simple read( want 32 )
/sbin/xfsrestore: drive_simple return_read_buf( returning 32 )
/sbin/xfsrestore: xlate_extenthdr
/sbin/xfsrestore: read extent hdr size 0 offset 0 type 0 flags 00000001
/sbin/xfsrestore: read extent hdr type LAST offset 0 sz 0 flags 1
/sbin/xfsrestore: drive_simple get_mark( )
/sbin/xfsrestore: drive_simple read( want 256 )
/sbin/xfsrestore: drive_simple return_read_buf( returning 256 )
/sbin/xfsrestore: xlate_bstat
/sbin/xfsrestore: xlate_bstat: pre-xlate
	bs_ino 1705965962454368256
	bs_mode  20060200000
/sbin/xfsrestore: xlate_bstat: post-xlate
	bs_ino 98814635031
	bs_mode  140600
/sbin/xfsrestore: xlate_filehdr: pre-xlate
	fh_offset 0
	fh_flags 33554432
	fh_checksum 3550492224
/sbin/xfsrestore: xlate_filehdr: post-xlate
	fh_offset 0
	fh_flags 2
	fh_checksum 1077321939
/sbin/xfsrestore: read file hdr off 0 flags 0x2 ino 98814635031 mode 0x0000c180
/sbin/xfsrestore: restoring secondary/[...]/etc/socket (98814635031 2812586625)
/sbin/xfsrestore: restoring UNIX domain socket ino 98814635031 secondary/[...]/etc/socket

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff211e700 (LWP 23393)]
0x00000033fd8478de in vfprintf () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.80.el6_3.6.x86_64 glibc-2.12-1.80.el6_3.7.x86_64 libattr-2.4.44-7.el6.x86_64 
libuuid-2.17.2-12.7.el6_3.x86_64
(gdb) backtrace
#0  0x00000033fd8478de in vfprintf () from /lib64/libc.so.6
#1  0x000000000041b462 in mlog_va (levelarg=<value optimized out>, 
    fmt=0x448068 "pathname too long for bind of %s ino %llu %s: %s: discarding\n", args=0x7ffff211b530) at mlog.c:453
#2  0x000000000041b696 in mlog (levelarg=<value optimized out>, 
    fmt=<value optimized out>) at mlog.c:365
#3  0x000000000042a1dd in restore_spec (cp=<value optimized out>, 
    linkpr=<value optimized out>, 
    path1=0x7fffec0008c0 "secondary/[...]/etc/socket", 
    path2=<value optimized out>) at content.c:7797
#4  restore_file_cb (cp=<value optimized out>, linkpr=<value optimized out>, 
    path1=0x7fffec0008c0 "secondary/[...]/etc/socket", 
    path2=<value optimized out>) at content.c:7299
#5  0x0000000000439d10 in tree_cb_links (ino=98814635031, gen=2812586625, 
    ctime=1358666583, mtime=1322084463, funcp=0x429560 <restore_file_cb>, 
    contextp=0x7ffff211cca0, 
    path1=0x7fffec0008c0 "secondary/[...]/etc/socket", 
    path2=0x7fffec0028d0 "../custom") at tree.c:1870
#6  0x0000000000430f50 in restore_file (thrdix=0) at content.c:7219
#7  applynondirdump (thrdix=0) at content.c:3459
#8  content_stream_restore (thrdix=0) at content.c:2543
#9  0x0000000000418ee6 in childmain (arg1=<value optimized out>) at main.c:1443
#10 0x0000000000407680 in cldmgr_entry (arg1=0x657420) at cldmgr.c:235
#11 0x00000033fdc07851 in start_thread () from /lib64/libpthread.so.0
#12 0x00000033fd8e811d in clone () from /lib64/libc.so.6

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

      reply	other threads:[~2013-02-17  3:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-16  6:20 xfsdump segfault Daniel Browning
2013-02-16  6:51 ` Dave Chinner
2013-02-17  0:06   ` Daniel Browning
2013-02-17  3:47     ` Daniel Browning [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201302161947.13836.db@kavod.com \
    --to=db@kavod.com \
    --cc=david@fromorbit.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.