Subject: Re: nbpax coredump on amd64 -current
To: Scott Ellis <scotte@warped.com>
From: Nicolas Joly <njoly@pasteur.fr>
List: current-users
Date: 10/16/2007 16:35:13
On Mon, Oct 15, 2007 at 06:18:33PM -0700, Scott Ellis wrote:
> Here's the deal...
> 
> ...using build.sh to rebuild -current (as of Oct 15th), the resultant 
> 'pax' binary works great, but 'nbpax' (part of the tools) segfaults as 
> soon as it starts to read a source file:
> 
> [snip..everything looks good, it reads /etc/group, and then...]
>   1388      1 nbpax    RET   read 409/0x199
>   1388      1 nbpax    CALL  close(7)
>   1388      1 nbpax    RET   close 0
>   1388      1 nbpax    PSIG  SIGSEGV SIG_DFL
>   1388      1 nbpax    NAMI  "nbpax.core"
> 
> 
> /data/scotte/netbsd_build/amd64/destdir/bin/pax:
>         -lutil.7 => /lib/libutil.so.7
>         -lc.12 => /lib/libc.so.12
> 
> /data/scotte/netbsd_build/amd64/tooldir/bin/nbpax:
>         -lz.1 => /usr/lib/libz.so.1
>         -lc.12 => /usr/lib/libc.so.12
> 
> This happens with the build.sh infrastructure, or simply by doing 'nbpax 
> -wf foo.pax blah' (where 'blah' is anything from a 1k text file to a 
> 118M binary blob).
> 
> A gdb backtrace shows:
> 
> Program terminated with signal 11, Segmentation fault.
> #0  0x00007f7ffdaa8ed8 in strncpy () from /usr/lib/libc.so.12
> (gdb) bt
> #0  0x00007f7ffdaa8ed8 in strncpy () from /usr/lib/libc.so.12
> #1  0x000000000040fdd7 in ustar_wr ()
> #2  0x0000000000405877 in wr_archive ()
> #3  0x00000000004059f6 in archive ()
> #4  0x000000000040d577 in main ()
> (gdb)
> 
> Am I the only one having this issue?

Same here. nbpax/nbmtree dumps core, while pax/mtree is ok.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.