zfs send -R segfault, anyone else?

8-CURRENT checked out yesterday morning (CEST) or so. According to the  
svn-head-list, I *think* no relevant changes has been made since then.  
A search through the archives (gzipped text) shows very little about  
zfs send at all.

So, long story short:

[root_at_vmware ~]# uname -a
FreeBSD vmware.exscape.org 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Thu May  
14 09:53:40 CEST 2009     root_at_vmware.exscape.org:/usr/obj/usr/src/sys/ 
DTRACE  amd64

[root_at_vmware ~]# zfs list
NAME                       USED  AVAIL  REFER  MOUNTPOINT
slave                       70K  13.7G    19K  /slave
tank                      3.15G  13.7G    18K  none
tank/root                 31.8M  13.7G  31.7M  legacy
tank/tmp                   542K  13.7G   542K  /tmp
tank/usr                  2.76G  13.7G  2.54G  /usr
tank/usr/ports             225M  13.7G   222M  /usr/ports
tank/usr/ports/distfiles  3.40M  13.7G  3.40M  /usr/ports/distfiles
tank/var                   360M  13.7G   359M  /var
[root_at_vmware ~]# zfs snapshot -r tank_at_now
[root_at_vmware ~]# zfs send -R tank_at_now | zfs recv -Fd slave
cannot receive: failed to read from stream
[root_at_vmware ~]# zfs send -R tank/usr/ports/distfiles_at_now > distfiles
Segmentation fault: 11 (core dumped)

Doesn't matter what snapshot I try to send, or if I send it to a pipe  
or a file (including one not on ZFS), it segfaults anyway.
Unfortunately, I don't have any debugging symbols in /lib (hmm, why  
not? All I've changed, IIRC, is to remove INVARIANTS and WITNESS from  
the kernel, and set MALLOC_PRODUCTION), so the backtrace looks like  
this:

#0  0x0000000800675a2d in zfs_prop_readonly () from /lib/libzfs.so.1
#1  0x0000000800659ea8 in fletcher_4_incremental_byteswap () from /lib/ 
libzfs.so.1
#2  0x000000080065a135 in fletcher_4_incremental_byteswap () from /lib/ 
libzfs.so.1
#3  0x000000080065aa53 in fletcher_4_incremental_byteswap () from /lib/ 
libzfs.so.1
#4  0x000000080065e49f in zfs_send () from /lib/libzfs.so.1
#5  0x0000000000406cda in ?? ()
#6  0x00000000004064c3 in ?? ()
#7  0x0000000000403c4e in ?? ()
.... on and on and on ...
#623 0x0000000000000000 in ?? ()
#624 0x0000000000000000 in ?? ()
#625 0x732f000000000000 in ?? ()
#626 0x0073667a2f6e6962 in ?? ()
#627 0x247c8d48002454ff in ?? ()
#628 0x01a1c0c748006a10 in ?? ()
---Type <return> to continue, or q <return> to quit---
#629 0x66fdebf4050f0000 in ?? ()
#630 0x9066669066669066 in ?? ()
#631 0x00007fffffffec80 in ?? ()
#632 0x0000000000000004 in ?? ()
#633 0x00007fffffffeca8 in ?? ()
#634 0x000000000000000e in ?? ()
Cannot access memory at address 0x800000000000
(gdb)

Can somebody reproduce this? Should be an easy task if it's a well- 
known problem, just snapshot, send -R a small dataset and see if it  
works or segfaults.

Regards,
Thomas

PS. FWIW, it does NOT crash on a regular zfs send:
zfs snapshot -r tank_at_now; for SNAP in $(zfs list -t snapshot -H -r  
tank | awk '/_at_now/ && !/tank_at_/ && !/tmp_at_/ {print $1}'); do echo $SNAP;  
zfs send $SNAP | zfs recv -d slave; done;
However, -R is a pretty nice feature, as is -I (capital i), and I'd  
really like to be able to use them!