From owner-freebsd-current@FreeBSD.ORG Thu May 14 09:29:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73B9C1065674 for ; Thu, 14 May 2009 09:29:55 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 091FE8FC18 for ; Thu, 14 May 2009 09:29:54 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:48728 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1M4XFf-000862-4n for freebsd-current@freebsd.org; Thu, 14 May 2009 11:29:21 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 15B0A7D798 for ; Thu, 14 May 2009 11:29:18 +0200 (CEST) Message-Id: <08D1E6DF-89D3-4887-9234-C3DB9164D794@exscape.org> From: Thomas Backman To: freebsd-current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 14 May 2009 11:29:17 +0200 X-Mailer: Apple Mail (2.930.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1M4XFf-000862-4n. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1M4XFf-000862-4n 87432fdbb84c422e51f4450904aba117 Subject: zfs send -R segfault, anyone else? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 09:29:55 -0000 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@vmware ~]# uname -a FreeBSD vmware.exscape.org 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Thu May 14 09:53:40 CEST 2009 root@vmware.exscape.org:/usr/obj/usr/src/sys/ DTRACE amd64 [root@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@vmware ~]# zfs snapshot -r tank@now [root@vmware ~]# zfs send -R tank@now | zfs recv -Fd slave cannot receive: failed to read from stream [root@vmware ~]# zfs send -R tank/usr/ports/distfiles@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 to continue, or q 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@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!