Re: zsh eats 100% CPU with completion in /

[Mikael Magnusson <mikachu@xxxxxxxxx>]

2009/10/31 Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>:
> Mikael Magnusson wrote:
>> 2009/10/30 Mikael Magnusson <mikachu@xxxxxxxxx>:
>> > 2009/10/30 Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx>:
>> >> The subject is not entirely correct.
>> >>
>> >> Zsh eats 100% CPU on a colleague's laptop if you do this:
>> >> % cd /
>> >> % cd ..
>> >> % ./<tab>
>
> Thanks for the additional details.
>
> So it appears something's going on in this loop in get_comp_string()
> around line 1439 of zle_tricky.c:
>
>        for (tt = s; tt < s + zlemetacs_qsub - wb;) {
>            if (*tt == Inbrack) {
>                i++;
>                nb = nnb;
>                ne = tt;
>                tt++;
>            } else if (i && *tt == Outbrack) {
>                i--;
>                tt++;
>            } else {
>                int nclen = MB_METACHARLEN(tt);
>                if (itype_end(tt, IIDENT, 1) == tt)
>                    nnb = tt + nclen;
>                tt += nclen;
>            }
>        }
>
> It would therefore probably help to know what the various quantities are
> in this loop: tt, s, zlemetacs_qsub and wb in particular, and also what
> nclen is being returned.  (You might need a debugging build to get these
> out.)  It seems plausible nclen is zero, which obviously causes a
> problem.  If eveything's in range (and unless we're going backwards the
> loop test suggests it should be) this presumably means we encountered a
> character we didn't like somewhere, so possibly the LC_CTYPE locale is
> useful (I would guess it's UTF-8).

Yes, my LC_CTYPE is en_US.UTF-8, here's a bt full

#0  0x6fae4a7b in get_comp_string () at zle_tricky.c:1439
        nnb = 0x82d7248 ""
        nb = 0x0
        ne = 0x0
        t0 = 34
        tt0 = 34
        i = 0
        j = 0
        k = 0
        cp = 1
        rd = 0
        sl = 1
        ocs = 0
        ins = 0
        oins = 0
        ia = 0
        parct = 0
        varq = 0
        ona = 0
        qsub = 0
        zlemetacs_qsub = 2
        redirpos = 0
        s = 0x82d7248 ""
        tmp = 0x80ff770 "./"
        p = 0x0
        tt = 0x82d7248 ""
        rdop = "\000\367\017\b\370\031\244wq\367\017\b\001\000\000\000h0\031\b"
        linptr = 0x6ffed840 "./x"
        u = 0x80ff772 ""
#1  0x6fae22bc in docomplete (lst=4) at zle_tricky.c:659
        s = 0x41b6cedb "\201\303\031\301\v"
        ol = 0x0
        olst = 4
        chl = 0
        ne = 0
        ocs = 2
        ret = 0
        dat = {1878464192, 2007243640}
        active = 1
#2  0x6fae175f in expandorcomplete (args=0x6faf7d40) at zle_tricky.c:315
        ret = 2007244248
#3  0x6fae1302 in completecall (args=0x6faf7d40) at zle_tricky.c:208
No locals.

and inside the last bit
(gdb) print zlemetacs_qsub
$3 = 2
get_comp_string () at zle_tricky.c:1450
1450			if (itype_end(tt, IIDENT, 1) == tt)
(gdb) print nclen
$7 = 0
(gdb) print tt
$8 = 0x82d7248 ""

As a curiousity, I couldn't reproduce the bug as my user now, but it
"worked" as root, or if I did the cd .. twice.

-- 
Mikael Magnusson