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.