From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9760 invoked by alias); 2 Nov 2009 16:39:13 -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: 27335 Received: (qmail 20258 invoked from network); 2 Nov 2009 16:39:11 -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.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received-SPF: none (ns2.melb.primenet.com.au: domain at csr.com does not designate permitted sender hosts) Date: Mon, 2 Nov 2009 16:38:58 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: zsh eats 100% CPU with completion in / Message-ID: <20091102163858.11415153@news01> In-Reply-To: <237967ef0911011726q7550593ax30bc61f1a736e725@mail.gmail.com> References: <237967ef0911011312u307ecf19kbabf9fecf867cec1@mail.gmail.com> <200911012220.nA1MKgjM005270@pws-pc.ntlworld.com> <237967ef0911011657n54279c54ja8fce16a1861ff4f@mail.gmail.com> <237967ef0911011726q7550593ax30bc61f1a736e725@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: 02 Nov 2009 16:38:59.0296 (UTC) FILETIME=[FA3FBE00:01CA5BDA] X-Scanned-By: MailControl A-09-22-03 (www.mailcontrol.com) on 10.71.0.123 On Mon, 2 Nov 2009 02:26:54 +0100 Mikael Magnusson wrote: > Well, I obviously have no idea what I'm doing now, first I just tried > breaking on > gettok, but it went on and on forever, then i started doing s 100 and > it still took > a good while until we came to the infinite loop. Then I tried the new reversible > debugging thing in gdb 7, breaked on zshlex, then continued backward > to gettok, and > stepped forward from there. I'm not exactly sure if I went far enough though. Thanks again. Somehow you've got tokstr equal to "." rather then either "" or "./x" in this case. That might be consistent---at that point we haven't removed the "x", so we might remove what we think is the "x" while it's actually the ".", ending up with the "" we see later. That would imply the end index is two too short. tmp is from zlemetaline: that's OK, "./", except the "x" has disappeared already. That happens at zle_tricky.c:1259. I didn't think you'd got that far yet, but I'm quite confused about what's actually happening, so it may be this is a red herring (it doesn't seem to fit with the other evidence). The key thing to find out (probably) is how gettokstr() puts together the string it's returning, which should be "./x", and how zle fudges it. There are no special characters in that, so we should bypass the switch at lex.c:975 each time until we get to the end of the input. So we should be calling add('.'), add('/'), add('x'). I see three calls to add in the trace, followed by hitting LX2_BREAK, which would be OK for the end of the string but I've no idea if it corresponds to that or not. Those "*bptr++ = c"s ought to be a help: that's where we're appending to tokstr. I see three of those following by a "*bptr = '\0'", which looks right. It might be worth tracking the value of tokstr after that point ("d tokstr" would probably do it). I think the nasty fix-up-for-zle code in zle is the stuff in exalias() around the call to gotwork(). This is grotesque and uncommented, so I'm not sure what it's doing, but if it's working it should leave tokstr as "./x". We're returning from inside that code at line 1745, which I presume is correct, but I don't know, it's just too opaque. gotword() should be setting "we" (the word end index) to 2 (or maybe 3? This is full of opaque adjustments, too), and "wb" (the word beginning) to 0. (Hmm... even if tokstr were "./x" an incorrect "we" might screw it up, but from other evidence it looks likes it's getting to be "." somehow.) Anyway, I wouldn't be surprised if the difference from the working case was down here, somewhere, with the end index getting fudged wrongly, so if you can work out how to break on the right gettok() or gettokstr() you should "just" be able to post traces for both cases. Maybe if we work out what's happening we can even stick some comments in the code... -- 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