Re: zfs send -R segfault, anyone else?

From: Thomas Backman <serenity_at_exscape.org>
Date: Sun, 28 Jun 2009 22:14:16 +0200
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_at_chaos ~]# zfs send -R -I $OLD tank_at_$NOW > diff-snap
>>> [root_at_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
>
Any news on this? The bug's been around for a long time, and a fix has  
been 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
===================================================================
--- cddl/contrib/opensolaris/lib/libzfs/common/ 
libzfs_sendrecv.c        (revision 194851)
+++ cddl/contrib/opensolaris/lib/libzfs/common/ 
libzfs_sendrecv.c        (working copy)
_at__at_ -239,6 +239,8 _at__at_
                 char *propname = nvpair_name(elem);
                 zfs_prop_t prop = zfs_name_to_prop(propname);
                 nvlist_t *propnv;
+               if (prop == ZPROP_INVAL)
+                   continue;

                 if (!zfs_prop_user(propname) &&  
zfs_prop_readonly(prop))
                         continue;
_at__at_ -1126,7 +1128,7 _at__at_
                 uint64_t originguid = 0;
                 uint64_t stream_originguid = 0;
                 uint64_t parent_fromsnap_guid,  
stream_parent_fromsnap_guid;
-               char *fsname, *stream_fsname;
+               char *fsname, *stream_fsname, *p1, *p2;

                 nextfselem = nvlist_next_nvpair(local_nv, fselem);

_at__at_ -1295,10 +1297,13 _at__at_
                     "parentfromsnap", &stream_parent_fromsnap_guid));

                 /* check for rename */
+               p1 = strrchr(fsname, '/');
+               p2 = strrchr(stream_fsname, '/');
+
                 if ((stream_parent_fromsnap_guid != 0 &&
                     stream_parent_fromsnap_guid !=  
parent_fromsnap_guid) ||
-                   strcmp(strrchr(fsname, '/'),
-                   strrchr(stream_fsname, '/')) != 0) {
+                   (p1 != NULL && p2 != NULL && strcmp (p1, p2) != 0)  
||
+                    ((p1 == NULL) ^ (p2 == NULL))) {
                         nvlist_t *parent;
                         char tryname[ZFS_MAXNAMELEN];

_at__at_ -1317,7 +1322,7 _at__at_
                                 VERIFY(0 ==  
nvlist_lookup_string(parent, "name",
                                     &pname));
                                 (void) snprintf(tryname, sizeof  
(tryname),
-                                   "%s%s", pname,  
strrchr(stream_fsname, '/'));
+                               "%s%s", pname, p2 ? p2 : "");
                         } else {
                                 tryname[0] = '\0';
                                 if (flags.verbose) {
Received on Sun Jun 28 2009 - 18:14:30 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:50 UTC