From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 20:41:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0168210656D3; Sun, 28 Jun 2009 20:41:45 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 944EA8FC1B; Sun, 28 Jun 2009 20:41:44 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so1025414and.13 for ; Sun, 28 Jun 2009 13:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=1OnplT3p5OCapLXx/SxCJPs3LkFMoDKbfg8GXZzX3kg=; b=T0aA1XuAqQjTrNbxsosHb0xphryWFCKPbj6/1DHqSea4ZL4F2YxOzMf6XkacErAbbl SDhIXBvxgMWTADvXUHi+VZjGuw6Ar54N/Uy1+/QoK/9ka5uIL3Br4dhwIGjL/Hb0TAVk q/3rTO34v85WnLcpjVwCXl3iKi9igTE30glJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=VJF4SQzAy0C8XpHlCxOFrAnzZ1cs7rf9qB79LP08Os9SOAM3y86vDO25l6xOXhkmYm kbN1yY3THi4TESkL9aJDJXPmPVrxflpjTi5OBRwo4weOqp9j9aSKt2xoroK6QZ45l/Er UEif+1OEUKg0qqSV/LgJ4CIekOaVeqrGv4PPk= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.251.6 with SMTP id y6mr8115892anh.44.1246221703553; Sun, 28 Jun 2009 13:41:43 -0700 (PDT) In-Reply-To: <09277772-9C54-4AE6-A147-CB6A4ED38C48@exscape.org> References: <08D1E6DF-89D3-4887-9234-C3DB9164D794@exscape.org> <20090514133017.362075dhcdy7o2bs@webmail.leidinger.net> <7CD27FF0-CBFA-48B7-9E18-763D8C3ED9B8@exscape.org> <4A0C9B0C.4050403@jrv.org> <09277772-9C54-4AE6-A147-CB6A4ED38C48@exscape.org> Date: Sun, 28 Jun 2009 13:41:43 -0700 X-Google-Sender-Auth: 8e6ff7087de777d1 Message-ID: <3c1674c90906281341w4b235dd7y809e1b23978ad5c3@mail.gmail.com> From: Kip Macy To: Thomas Backman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, FreeBSD current Subject: Re: zfs send -R segfault, anyone else? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 20:41:45 -0000 I'm a bit preoccupied at the moment. Keep reminding me ... -Kip On Sun, Jun 28, 2009 at 1:14 PM, Thomas Backman wrote= : > On May 15, 2009, at 11:30 AM, Thomas Backman wrote: >> >> On May 15, 2009, at 12:28 AM, James R. Van Artsdalen wrote: >> >>> Thomas Backman wrote: >>>> >>>> [root@chaos ~]# zfs send -R -I $OLD tank@$NOW > diff-snap >>>> [root@chaos ~]# cat diff-snap | zfs recv -Fvd slave >>>> Segmentation fault: 11 (core dumped) >>>> >>>> Same kinda backtrace, but what's up with strcmp()? >>>> I suppose the issue stems from libzfs, and is not within libc: >>> >>> Different problem =A0The SIGSEGV is happening in strcmp because it is >>> called with strcmp(0,0) >>> and tries to dereference address -4 (probably another bug itself). >>> >>> This hack gets around the issue but someone familiar with this needs to >>> decide the correct action. >>> >>> The first change is actually unrelated (a sorry attempt at fixing the >>> previous zfs send bug). >>> >>> The last change may be unnecessary as that case may never happen unless >>> the pool can be renamed? >>> >>> [... patch ...] >> >> Thanks! This list is pretty impressive. :) >> I can't validate how correct the fix is, considering my lacking knowledg= e >> in C (I know the basics, but kernel/related programming? no way!), but I= CAN >> say that it appears to work just fine! >> >> Regards, >> Thomas >> > Any news on this? The bug's been around for a long time, and a fix has be= en > around for at least 1.5 months now, and AFAIK the bug still lives. > The patch, again (I can't vouch for its correctness, but I can certainly = say > that it works just fine *for me*) follows. > > Regards, > Thomas > > Index: cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c > =A0(revision 194851) > +++ cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c > =A0(working copy) > @@ -239,6 +239,8 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *propname =3D nvpair_name(elem); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0zfs_prop_t prop =3D zfs_name_to_prop(propn= ame); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nvlist_t *propnv; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (prop =3D=3D ZPROP_INVAL) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!zfs_prop_user(propname) && zfs_prop_r= eadonly(prop)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; > @@ -1126,7 +1128,7 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint64_t originguid =3D 0; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint64_t stream_originguid =3D 0; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint64_t parent_fromsnap_guid, stream_pare= nt_fromsnap_guid; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *fsname, *stream_fsname; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *fsname, *stream_fsname, *p1, *p2; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nextfselem =3D nvlist_next_nvpair(local_nv= , fselem); > > @@ -1295,10 +1297,13 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"parentfromsnap", &stream_parent_f= romsnap_guid)); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* check for rename */ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 p1 =3D strrchr(fsname, '/'); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 p2 =3D strrchr(stream_fsname, '/'); > + > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ((stream_parent_fromsnap_guid !=3D 0 && > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0stream_parent_fromsnap_guid !=3D p= arent_fromsnap_guid) || > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 strcmp(strrchr(fsname, '/'), > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 strrchr(stream_fsname, '/')) !=3D 0= ) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (p1 !=3D NULL && p2 !=3D NULL && st= rcmp (p1, p2) !=3D 0) || > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0((p1 =3D=3D NULL) ^ (p2 =3D=3D N= ULL))) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nvlist_t *parent; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char tryname[ZFS_MAXNAMELE= N]; > > @@ -1317,7 +1322,7 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0VERIFY(0 = =3D=3D nvlist_lookup_string(parent, > "name", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&p= name)); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(void) snp= rintf(tryname, sizeof (tryname), > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "%s= %s", pname, strrchr(stream_fsname, > '/')); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "%s%s", pna= me, p2 ? p2 : ""); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tryname[0]= =3D '\0'; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (flags.= verbose) { > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke