Bug#353863: Bugreport: completion hanging at ubo - endless loop

February 23rd, 2011 - 06:00 am ET by Michael Prokop | Report spam

Hi,

in http://bugs.debian.org/cgi-bin/bugr...bug=353863
Sebastien Desreux reported a bug about zsh with its
completion system in a specific situation.

To trigger the bug (at least 4.3.10 and 4.3.11 in Debian are
known to be affected by this bug):

zsh -f
autoload -Uz compinit; compinit; alias ubox=ls
ubo<tab>

Then the zsh process is hanging in an endless loop, eating CPU.

I've just stepped down the problem in gdb, it seems to be hanging in
this code forever (I've extracted the relevant parts that
repeat-and-repeat-again out of my gdb session, hope this helps):

,- [ gdb session - the relevant parts / the endless loop ]
| get_comp_string (lst=4) at ../../../Src/Zle/zle_tricky.c:1487
| nnb = tt + nclen;
| nnb = tt + nclen;
| for (tt = s; tt < s + zlemetacs_qsub - wb;) {
| if (*tt == Inbrack) {
| } else if (i && *tt == Outbrack) {
| int nclen = MB_METACHARLEN(tt);
| mb_metacharlenconv (s=0x23aaf32 "", wcp=0x0) at ../../Src/utils.c:4439
| if (!isset(MULTIBYTE)) {
| if (itok(*s)) {
| return mb_metacharlenconv_r(s, wcp, &mb_shiftstate);
| mb_metacharlenconv_r (s=0x23aaf32 "", wcp=0x0, mbsp=0x6b1f30) at ../../Src/utils.c:4389
| {
| ret = mbrtowc(&wc, &inchar, 1, mbsp);
| {
| for (ptr = s; *ptr; ) {
| if (wcp)
| if (ptr > s) {
| memset(mbsp, 0, sizeof(*mbsp));
| if (ptr > s) {
| }
| get_comp_string (lst=4) at ../../../Src/Zle/zle_tricky.c:1486
| if (itype_end(tt, IIDENT, 1) == tt)
| int nclen = MB_METACHARLEN(tt);
| if (itype_end(tt, IIDENT, 1) == tt)
| itype_end (ptr=0x23aaf32 "", itype=128, once=1) at ../../Src/utils.c:3491
| {
| if (isset(MULTIBYTE) &&
| (itype != IIDENT || !isset(POSIXIDENTIFIERS))) {
| mb_metacharinit();
| mb_metacharinit () at ../../Src/utils.c:449
| memset(&mb_shiftstate, 0, sizeof(mb_shiftstate));
| mb_metacharinit () at ../../Src/utils.c:450
| }
| itype_end (ptr=0x23aaf32 "", itype=128, once=1) at ../../Src/utils.c:3498
| int len = mb_metacharlenconv(ptr, &wc);
| while (*ptr) {
| }
`-

regards,
-mika-
http://michael-prokop.at/ || http://adminzen.org/
http://grml-solutions.com/ || http://grml.org/






To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
email Follow the discussionReplies 3 repliesReplies Make a reply

Replies

#1 Peter Stephenson
February 23rd, 2011 - 06:40 am ET | Report spam
On Wed, 23 Feb 2011 11:50:18 +0100
Michael Prokop wrote:
in http://bugs.debian.org/cgi-bin/bugr...i?bug53863
Sebastien Desreux reported a bug about zsh with its
completion system in a specific situation.

To trigger the bug (at least 4.3.10 and 4.3.11 in Debian are
known to be affected by this bug):

zsh -f
autoload -Uz compinit; compinit; alias ubox=ls
ubo<tab>

Then the zsh process is hanging in an endless loop, eating CPU.



Tee hee. This is what happens when your interface between the
completion system and the main shell is a complete hack.

If the option COMPLETE_ALIASES is off, the shell tries to expand
aliases, so it can do completion for aliased commands without the
completion system needing to understand the alias.

To analyse a command line to find the current context, completion adds
an "x" at the cursor position which it later removes. In this case, the
"x" completes the word "ubox", which is then expanded to "ls". The
completion system doesn't notice and assumes it still has the original
command line. It removes the non-existent "x" to get "l" which it
thinks is three characters long. It then loops for ever reading the
null byte at the end of the string waiting to get to the third
character.

I think the answer might be never to expand aliases when the "x" would
be added to the command word. That might be easier said than done.

Peter Stephenson
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Similar topics