Re: zfs send -R segfault, anyone else?

On May 14, 2009, at 01:30 PM, Alexander Leidinger wrote:

> Quoting Thomas Backman <serenity_at_exscape.org> (from Thu, 14 May 2009  
> 11:29:17 +0200):
>
>> 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.
>
> Fix in:
> http://www.nabble.com/Patch-for-%27zfs-send--R%27-core-dump-%28pr-bin-130105%29-td22106451.html
>
> Bye,
> Alexander.


OK, a follow-up... It worked, BUT now *recv* is crashing in the same  
way, when trying to receive an incremental backup (recv -Fvd):

[root_at_chaos ~]# zfs send -R -I $OLD tank_at_$NOW | zfs recv -Fvd slave
warning: cannot send 'tank/var_at_backup-20090514-2128': Broken pipe
Segmentation fault: 11 (core dumped)
[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:

[root_at_chaos ~]# gdb /sbin/zfs zfs.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging  
symbols found)...

warning: exec file is newer than core file. ### Due to a TZ difference  
during installworld
Core was generated by `zfs'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libzfs.so.1...(no debugging symbols  
found)...done.
Loaded symbols for /lib/libzfs.so.1
Reading symbols from /lib/libgeom.so.4...(no debugging symbols  
found)...done.
Loaded symbols for /lib/libgeom.so.4
Reading symbols from /lib/libbsdxml.so.3...(no debugging symbols  
found)...done.
Loaded symbols for /lib/libbsdxml.so.3
Reading symbols from /lib/libsbuf.so.4...(no debugging symbols  
found)...done.
Loaded symbols for /lib/libsbuf.so.4
Reading symbols from /lib/libm.so.5...(no debugging symbols  
found)...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libnvpair.so.1...(no debugging symbols  
found)...done.
Loaded symbols for /lib/libnvpair.so.1
Reading symbols from /lib/libuutil.so.1...(no debugging symbols  
found)...done.
Loaded symbols for /lib/libuutil.so.1
Reading symbols from /lib/libutil.so.7...(no debugging symbols  
found)...done.
Loaded symbols for /lib/libutil.so.7
Reading symbols from /lib/libc.so.7...(no debugging symbols  
found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols  
found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x0000000800fc466c in strcmp () from /lib/libc.so.7
(gdb) bt
#0  0x0000000800fc466c in strcmp () from /lib/libc.so.7
#1  0x000000080065c02c in fletcher_4_incremental_byteswap () from /lib/ 
libzfs.so.1
#2  0x000000080065c894 in fletcher_4_incremental_byteswap () from /lib/ 
libzfs.so.1
#3  0x000000080065cffc in fletcher_4_incremental_byteswap () from /lib/ 
libzfs.so.1
#4  0x000000080065de2c in zfs_receive () from /lib/libzfs.so.1
#5  0x0000000000406a40 in ?? ()
........
#629 0x0000000000000000 in ?? ()
#630 0x0000000000000000 in ?? ()
#631 0x732f000000000000 in ?? ()
#632 0x0073667a2f6e6962 in ?? ()
#633 0x247c8d48002454ff in ?? ()
#634 0x01a1c0c748006a10 in ?? ()
#635 0x66fdebf4050f0000 in ?? ()
#636 0x9066669066669066 in ?? ()
#637 0x00007fffffffec58 in ?? ()
#638 0x0000000000000004 in ?? ()
#639 0x00007fffffffec80 in ?? ()
---Type <return> to continue, or q <return> to quit---
#640 0x0000000000000010 in ?? ()
Cannot access memory at address 0x800000000000
(gdb) quit

In case it might matter, and I guess it COULD, tank is ZFS ver 6,  
slave ver 13 - not
ready to upgrade until I have *some* stability. Still, the same  
happened with 6 vs 6 and send.

Oh, and sorry if this (too) has been up. Just trying to make sure this  
stuff
is production-class by 8.0-RELEASE, both for my own and others' sake. ;)

Regards,
Thomas