Re: zsh eats 100% CPU with completion in /

[Peter Stephenson <pws@csr.com>]

On Mon, 2 Nov 2009 02:26:54 +0100
Mikael Magnusson <mikachu@gmail.com> 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 <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