From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 148 invoked by alias); 2 Nov 2009 20:58:22 -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: 27336 Received: (qmail 8063 invoked from network); 2 Nov 2009 20:58:19 -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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 209.85.219.207 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+9M9UWgfbFPFIOVy904tA7iKpsRK522Fa00AfS5SvMc=; b=wCutyB6MiJBJb3PBX5aMBJ3XuQkd6/lSKgaeN2uIsGNFf3pMe2gublOm63hCR8W02N 9v3C53Qcwm0LsJjEU+8yANvKl9GE5nws1SEXqCexwKGJ0/KtYSg5+rCJCwZKmuvdl3+K SJweX23Oapofp3gubCgFeJAQ4NmGV6Q+/AgMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VeRkMM+y61B0cgJe5EQ4N5UUVP1hMtWh4JjuHvphY/0syJZ964fn1fIvEiUvHLd1GY +Vm/CYYVQUWljs3mBFc5OnEuq0yHdTb6WERsTwxnd0NLTPf2dr2Hw2ccYY4Tcu7lT2rX WYSCZJ9lpPztD4Hq50h29g3xVCVfbZP5WAGm4= MIME-Version: 1.0 In-Reply-To: <20091102163858.11415153@news01> References: <237967ef0911011312u307ecf19kbabf9fecf867cec1@mail.gmail.com> <200911012220.nA1MKgjM005270@pws-pc.ntlworld.com> <237967ef0911011657n54279c54ja8fce16a1861ff4f@mail.gmail.com> <237967ef0911011726q7550593ax30bc61f1a736e725@mail.gmail.com> <20091102163858.11415153@news01> Date: Mon, 2 Nov 2009 21:58:13 +0100 Message-ID: <237967ef0911021258x5403c976m281fb66ee7488b59@mail.gmail.com> Subject: Re: zsh eats 100% CPU with completion in / From: Mikael Magnusson To: Peter Stephenson Cc: zsh-workers@zsh.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2009/11/2 Peter Stephenson : > 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 re= versible >> 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 th= ough. > > 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 t= he > "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 th= at > far yet, but I'm quite confused about what's actually happening, so it ma= y > 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. The= re > 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 b= e > 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 th= e > string but I've no idea if it corresponds to that or not. > > Those "*bptr++ =3D c"s ought to be a help: that's where we're appending t= o > tokstr. I see three of those following by a "*bptr =3D '\0'", which look= s > 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 presu= me > 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 opaq= ue > adjustments, too), and "wb" (the word beginning) to 0. > > (Hmm... even if tokstr were "./x" an incorrect "we" might screw it up, bu= t > 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 w= as > down here, somewhere, with the end index getting fudged wrongly, so if yo= u > 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... I found something now, but I'm not sure if it's the gdb record log being we= ird. It looks like lextok2['/'] is 0, which ends up making tokstr not "." as we thought, but ".\000x" (maybe). I did try the whole thing without any recording and this is what I see: Breakpoint 1, get_comp_string () at zle_tricky.c:1067 1067 int t0, tt0, i, j, k, cp, rd, sl, ocs, ins, oins, ia, parct, varq = =3D 0; then a lot of stepping to 1164 ctxtlex(); then (gdb) print tokstr $1 =3D 0x6fb71758 "." (gdb) print tokstr+1 $2 =3D 0x6fb71759 "" (gdb) print tokstr+2 $3 =3D 0x6fb7175a "x" (gdb) print tokstr+3 $4 =3D 0x6fb7175b "" Here are some other variables (gdb) print bptr $10 =3D 0x6fb7175b "" (gdb) print bptr-1 $11 =3D 0x6fb7175a "x" (gdb) print bptr-2 $12 =3D 0x6fb71759 "" (gdb) print bptr-3 $13 =3D 0x6fb71758 "." (gdb) print bptr-4 $14 =3D 0x6fb71757 "" (gdb) print inbuf $15 =3D 0x6fb71750 "./x " (gdb) print inbufptr $16 =3D 0x6fb71753 " " (gdb) print inbufct $17 =3D 1 (gdb) print inbufleft $18 =3D 1 Tried that again and stepped into ctxtlex a bit, and Breakpoint 2, ctxtlex () at lex.c:408 408 zshlex(); (gdb) print tokstr $2 =3D 0x0 (gdb) s zshlex () at lex.c:361 361 if (tok =3D=3D LEXERR) (gdb) n 364 tok =3D gettok(); (gdb) 365 while (tok !=3D ENDINPUT && exalias()); (gdb) print tokstr $3 =3D 0x6fb23758 "." (gdb) print tokstr+1 $4 =3D 0x6fb23759 "" (gdb) print tokstr+2 $5 =3D 0x6fb2375a "x" (gdb) print tokstr+3 $6 =3D 0x6fb2375b "" So I don't think it's exalias() that's breaking it? So far I have no idea how all this works though, has all this already been called one (or more) times by the time we call it from get_comp_string()? Just confirmed ['/'] is set to 0 by doing cd .. in / Here we are, (gdb) watch lextok2['/'] Hardware watchpoint 9: lextok2['/'] Continuing. Hardware watchpoint 9: lextok2['/'] Old value =3D 47 '/' New value =3D 0 '\000' 0x080c962f in xsymlinks (s=3D0x818e8f1 "..") at utils.c:696 696 *p =3D '\0'; (start over and add breakpoints (i'm not in reversible now just to be safe)= ) 692 if (!strcmp(xbuf, "/")) (gdb) print xbuf $22 =3D '\000' (gdb) n 694 p =3D xbuf + strlen(xbuf); (gdb) 695 while (*--p !=3D '/'); (gdb) n at this point i pressed ctrl-c because i was curious what was taking so long. Apparently this loops over all memory until it finds a slash, which takes a while under gdb. Also apparently, the first / it finds is in lextok2. Amusingly, ctrl-c and breaking on the next line is instant, compared to waiting 30 seconds for 'n' to finish. Breakpoint 11, xsymlinks (s=3D0x818e8f1 "..") at utils.c:696 696 *p =3D '\0'; (gdb) print p $25 =3D 0x80e9b6f "/0123456789:;<=3D>\225@ABCDEFGHIJKLMNOPQRSTUVWXYZ\217\\]\206_`abcdefghijkl= mnopqrstuvwxyz\215|}\226\177\200\201\202\203\204\205\206\207\210\211\212\21= 3\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\2= 36\237\240\241\242\243\244\245\246\247\250\251\252\253\254\255\256\257\260\= 261\262\263\264\265\266\267\270\271\272\273\274\275\276\277\300\301\302\303= \304\305\306\307\310\311\312\313\314\315\316\317\320\321\322\323\324\325\32= 6\327\330\331\332\333\334\335\336\337\340\341\342\343\344\345\346\347\350\3= 51\352\353\354\355\356\357\360\361\362\363\364\365", ... --=20 Mikael Magnusson