zfs send -R segfault, anyone else?
Thomas Backman
serenity at exscape.org
Thu May 14 09:29:55 UTC 2009
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 '/@now/ && !/tank@/ && !/tmp@/ {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!
More information about the freebsd-current
mailing list