ZFS v28: ZFS recv abort

[James R. Van Artsdalen]

amd64, SVN 212080 with pjd's original v28 patch

/sbin/zfs aborts receiving an incrementing stream.

bigback:/root# zfs send -R -I @then bigtex at now | ssh kraken /sbin/zfs
recv -dvF bigz
Assertion failed: (!clp->cl_alldependents), file
/usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_changelist.c,
line 470.

(the error message is from receiving system kraken)

At the failing ASSERT(!clp->cl_alldependents) clp points to

(gdb)  p * (prop_changelist_t *) data
$2 = {cl_prop = ZFS_PROP_MOUNTPOINT, cl_realprop = ZFS_PROP_NAME,
cl_shareprop = ZFS_PROP_TYPE, cl_pool = 0x8018a8400, cl_list =
0x802243c50, cl_waslegacy = B_FALSE, cl_allchildren = B_FALSE, \
cl_alldependents = B_TRUE, cl_mflags = 524288, cl_gflags = 0,
cl_haszonedchild = B_FALSE, cl_sorted = B_FALSE}

One level up in parent function zfs_iter_dependents() zhp points to

(gdb) p *zhp
$3 = {zfs_hdl = 0x801810800, zpool_hdl = 0x801892140, zfs_name =
"bigz/recv-2818-1", '\0' <repeats 239 times>, zfs_type =
ZFS_TYPE_FILESYSTEM, zfs_head_type = ZFS_TYPE_FILESYSTEM, zfs_dmustats\
 = {dds_num_clones = 0, dds_creation_txg = 111554, dds_guid =
10368215686395422194, dds_type = DMU_OST_ZFS, dds_is_snapshot = 0 '\0',
dds_inconsistent = 0 '\0', dds_origin = '\0' <repeats 255 \
times>}, zfs_props = 0x801831040, zfs_user_props = 0x8018310c0,
zfs_recvd_props = 0x0, zfs_mntcheck = B_FALSE, zfs_mntopts = 0x0,
zfs_props_table = 0x0}

I'm guessing that the filesystem was renamed, hence the
"bigz/recv-2818-1" pool/dataset designation.  Or perhaps a prior recv
didn't properly change a temporary pool/recv-* dataset name back to the
right name after that prior recv, causing the next recv to fail.