Re: [PATCH] compdescribe fix for unsorted groups (workers/34814) (was: Re: completion: git: --fixup: problem with _describe -2V and duplicate commit subjects)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On May 20, 11:51pm, Daniel Shahaf wrote:
}
} While looking into this, I've also found a 100% CPU consumption bug; to
} reproduce (in master):
} 
}     autoload compinit
}     compinit
}     _f() { d=(d1); a=(); compadd -XX -JJ -E1 -d d -a a;  compadd -XX -JJ -E1 -d d -a a }; compdef _f f
}     f <TAB><TAB><TAB>
} 
} It's spinning in the outer of the two do-while loops in there, with
} minfo.cur being a dummy match.

It reaches the state where it has to try amatches, but the "default"
group to which amatches points contains only a CMF_DUMMY, so it won't
display it; thus it tries to go to the next match, but there are no
more, so back to amatches we go again, and loop.

So the obvious thing would seem to be to stop the loop if we arrive at
the "examine amatches" state twice, which is easy enough to do; but
then on a subsequent (fourth, if repeating the example above) attempt,
*++(minfo.cur) runs off the end of memory and the shell crashes on the
subsequent access through (*minfo.cur).

Thus the less-obvious thing to do is, upon discovering the twice-amatches
case, force everything back to the state it was in the second-to-last
time do_menucmp() was called, so we just loop displaying the menu in a
stable way.  Trouble is, I'm not sure where that state can be found.