From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9448 invoked by alias); 28 Jan 2011 10:24:29 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28667 Received: (qmail 6965 invoked from network); 28 Jan 2011 10:24:26 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at csr.com does not designate permitted sender hosts) Date: Fri, 28 Jan 2011 09:56:16 +0000 From: Peter Stephenson To: Subject: Re: coredump completing scp Message-ID: <20110128095616.18999141@pwslap01u.europe.root.pri> In-Reply-To: <110127193031.ZM4926@torch.brasslantern.com> References: <110127193031.ZM4926@torch.brasslantern.com> Organization: Cambridge Silicon Radio X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jan 2011 09:56:17.0091 (UTC) FILETIME=[9B2AD930:01CBBED1] X-Scanned-By: MailControl A_10_80_00 (www.mailcontrol.com) on 10.71.0.123 On Thu, 27 Jan 2011 19:30:31 -0800 Bart Schaefer 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 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