Bugreport: completion hanging at ubo<Tab> - endless loop

Bugreport: completion hanging at ubo<Tab> - endless loop

[Michael Prokop]

[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]

Hi,

in http://bugs.debian.org/cgi-bin/bugreport.cgi?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/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Bugreport: completion hanging at ubo<Tab> - endless loop

[Peter Stephenson]

On Wed, 23 Feb 2011 11:50:18 +0100
Michael Prokop <news@michael-prokop.at> wrote:
> in http://bugs.debian.org/cgi-bin/bugreport.cgi?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.

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 <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Bugreport: completion hanging at ubo<Tab> - endless loop

[Bart Schaefer]

On Wednesday, February 23, 2011, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
>
> 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.

Maybe the right thing to do here is insert something other than an "x"
-- a metafied character, for example, something that can't appear in
normal input.  Unfortunately I'm not able to look at the source at the
moment so I don't know whether the string is already metafied at that
point.  At least pick something less likely to form part of an actual
word.

Re: Bugreport: completion hanging at ubo<Tab> - endless loop

[Peter Stephenson]

On Wed, 23 Feb 2011 11:30:04 +0000
Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> On Wed, 23 Feb 2011 11:50:18 +0100
> Michael Prokop <news@michael-prokop.at> wrote:
> > in http://bugs.debian.org/cgi-bin/bugreport.cgi?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 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.

Looks like this is my fault.  There's code to stop lexical processing
when we've got to the cursor position, which means the alias never gets
expanded, but when I upgraded the interface I missed the fact that it
was doing a test of lexflags against 1 and now needs to look for the bit
LEXFLAGS_ZLE.

Index: Src/lex.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/lex.c,v
retrieving revision 1.64
diff -p -u -r1.64 lex.c
--- Src/lex.c	21 Feb 2011 11:32:47 -0000	1.64
+++ Src/lex.c	24 Feb 2011 12:36:41 -0000
@@ -1825,7 +1825,7 @@ exalias(void)
 	    int zp = lexflags;
 
 	    gotword();
-	    if (zp == 1 && !lexflags) {
+	    if ((zp & LEXFLAGS_ZLE) && !lexflags) {
 		if (zshlextext == copy)
 		    zshlextext = tokstr;
 		return 0;

-- 
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