Re: coredump completing scp

[Peter Stephenson <Peter.Stephenson@csr.com>]

On Thu, 27 Jan 2011 19:30:31 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Jan 27, 10:13pm, Vin Shelton wrote:
> }
> } This shell was configured --with-zsh-mem and that seems to be
> required } to provoke the coredump.
> } 
> } #11 0x00007fd2d8b57ccc in setpwent () from /lib64/libc.so.6
> } #12 0x000000000043ecb4 in fillnameddirtable (ht=0x6e4b08) at
> hashtable.c:1382 } 
> } Please let me know if any further info is needed.

If you have valgrind, running "valgrind zsh -f" might be useful.  (I
don't think you'd need any of the options to look for leaked memory
for something like this.)

> Operating system and compiler?
> 
> This looks like an incompatibility of the libc free() which is
> being invoked from within setpwent() and the zsh-supplied memory
> routines.  There's probably not a lot to be done about it except to
> avoid using --with-zsh-mem on your platform.

It's calling free from libc, as they're paired presumably it's calling
malloc from the same place?

setpwent() is completely self-contained, though, so apart from a library
mismatch the only likely problem is trashed memory.  That setpwent()
is only used with NIS or NIS+, however valgrind still didn't
show up any errors on a RedHat x86_64 system using NIS.  Compiling
hashtable.c with -DHAVE_NIS and linking with -lnsl didn't show any
problems on my Fedora 13 Intel 32-bit system, either, but it wouldn't
find any NIS maps.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom