Re: zfs send -R segfault, anyone else?

I'm a bit preoccupied at the moment.

Keep reminding me ...


-Kip
On Sun, Jun 28, 2009 at 1:14 PM, Thomas Backman<serenity_at_exscape.org> 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_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) {
> _______________________________________________
> freebsd-fs_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe_at_freebsd.org"
>



-- 
When bad men combine, the good must associate; else they will fall one
by one, an unpitied sacrifice in a contemptible struggle.

    Edmund Burke