Date: Fri, 15 May 2009 11:30:22 +0200 From: Thomas Backman <serenity@exscape.org> To: James R. Van Artsdalen <james-freebsd-current@jrv.org> Cc: freebsd-current@freebsd.org Subject: Re: zfs send -R segfault, anyone else? Message-ID: <B7DA57FE-0109-44D2-A970-E7BE7F3C24C5@exscape.org> In-Reply-To: <4A0C9B0C.4050403@jrv.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 The 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 knowledge 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B7DA57FE-0109-44D2-A970-E7BE7F3C24C5>