From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5981 invoked by alias); 3 Nov 2009 10:11:15 -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: 27339 Received: (qmail 21908 invoked from network); 3 Nov 2009 10:11:12 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.2.5 Received-SPF: none (ns1.primenet.com.au: domain at csr.com does not designate permitted sender hosts) Date: Tue, 3 Nov 2009 10:10:58 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: zsh eats 100% CPU with completion in / Message-ID: <20091103101058.2eeaf4b6@news01> In-Reply-To: <237967ef0911021330r6f733a5v9536bbe2f237ccf9@mail.gmail.com> References: <237967ef0911011312u307ecf19kbabf9fecf867cec1@mail.gmail.com> <200911012220.nA1MKgjM005270@pws-pc.ntlworld.com> <237967ef0911011657n54279c54ja8fce16a1861ff4f@mail.gmail.com> <237967ef0911011726q7550593ax30bc61f1a736e725@mail.gmail.com> <20091102163858.11415153@news01> <237967ef0911021258x5403c976m281fb66ee7488b59@mail.gmail.com> <237967ef0911021306y33467270l6a1cf921cefbe037@mail.gmail.com> <237967ef0911021330r6f733a5v9536bbe2f237ccf9@mail.gmail.com> Organization: CSR X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.8; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2009 10:10:59.0191 (UTC) FILETIME=[F0A36070:01CA5C6D] X-Scanned-By: MailControl A-09-22-03 (www.mailcontrol.com) on 10.68.0.133 On Mon, 2 Nov 2009 22:30:08 +0100 Mikael Magnusson wrote: > > And this seems to fix it. Not sure if checking that inside the loop is the best > > place, but there seems to be some freeing of *pp going on that I > > didn't feel like > > investigating. Maybe checking xbuf before slashsplit would work? > > And of course, I have no idea if *xbuf being '\0' is indicative of > some other bug. Thanks, it looks like that really is the problem and I think the fix is fine. We only call xsymlinks() in two places (apart from recursive calls), and in both we initialise xbuf to contain '\0' as the first character. So on the first time through (!*xbuf) is the standard case, and this was being handled by searching backwards through memory for the first "/". So the bug you've found is a major one. The code around here is dependent (without checking) on paths being shorter than PATH_MAX (the factor of 2 is for metafication), which is another long-standing peeve of mine, but that's a completely separate problem. -- 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