Infinite loop (bug in wordcode evaluation?)

Infinite loop (bug in wordcode evaluation?)

[Bart Schaefer]

The following function reproduces the bug in an interactive shell with ZLE
active:

    function hang() {
	emulate -L zsh
	trap return HUP INT QUIT                                         
	for ((i=0; 1; i=0)) do
            tmp=()                                                  
            vared -p "Type ^C here: " tmp                       
        done                            
    }

If you interrupt this with ^C, 3.1.6-dev.16 goes into a loop repeatedly
evaluating the "for" expressions on an empty loop body.  The "trap" is
important.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Infinite loop (bug in wordcode evaluation?)

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Feb 4, 10:08am, Sven Wischnowsky wrote:
> } Subject: Re: Infinite loop (bug in wordcode evaluation?)
> }
> } Bart Schaefer wrote:
> } 
> } > } The problem is that none of the functions in loop.c check if retflag
> } > } is set and hence don't return.
> } > 
> } > I can't find any loop construct in 3.0.7 that produces this behavior,
> } > yet 3.0.7 does not have any of those extra retflag tests in loop.c.
> } > 
> } > Does anyone know what else might have changed to cause this problem?
> } 
> } Found it. getkey() in zle_main.c now resets `breaks' to the value it had 
> } before, so that the new value stored in bin_break() set by the signal
> } handler doesn't make it through to the execution code.
> } 
> } Dunno where this comes from, though.
> 
> It came from zsh-workers/7038, something to do with making _read_comp
> work correctly.

Yep. One could say that that patch explictly implemented the behaviour 
we now consider buggy. Almost. At least it makes a `break' in a signal 
handler have no effect if the signal arrives while we are reading with 
zle (and the handler for SIGINT has an implicit `break', breaking all
loops).

Hm. If 7038 is still considered to be correct, then my patch is
probably the right supplement for it to make `return' in signal
handlers work. At least I don't see another way out at the moment.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Infinite loop (bug in wordcode evaluation?)

[Bart Schaefer]

On Feb 4, 10:08am, Sven Wischnowsky wrote:
} Subject: Re: Infinite loop (bug in wordcode evaluation?)
}
} Bart Schaefer wrote:
} 
} > } The problem is that none of the functions in loop.c check if retflag
} > } is set and hence don't return.
} > 
} > I can't find any loop construct in 3.0.7 that produces this behavior,
} > yet 3.0.7 does not have any of those extra retflag tests in loop.c.
} > 
} > Does anyone know what else might have changed to cause this problem?
} 
} Found it. getkey() in zle_main.c now resets `breaks' to the value it had 
} before, so that the new value stored in bin_break() set by the signal
} handler doesn't make it through to the execution code.
} 
} Dunno where this comes from, though.

It came from zsh-workers/7038, something to do with making _read_comp
work correctly.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Infinite loop (bug in wordcode evaluation?)

[Sven Wischnowsky]

Bart Schaefer wrote:

> } The problem is that none of the functions in loop.c check if retflag
> } is set and hence don't return. But this was not changed by the
> } wordcode stuff  -- and a older zsh without that I have here behaves
> } the same. In fact, I think that zsh behaved this way either always or
> } for a long time.
> 
> I can't find any loop construct in 3.0.7 that produces this behavior,
> yet 3.0.7 does not have any of those extra retflag tests in loop.c.
> 
> Does anyone know what else might have changed to cause this problem?
> I want to understand it so that I don't leave a bug in 3.0.8.

Found it. getkey() in zle_main.c now resets `breaks' to the value it had 
before, so that the new value stored in bin_break() set by the signal
handler doesn't make it through to the execution code.

Dunno where this comes from, though. If it turns out that this is
wrong (at least doing it unconditionally as we do it now), we can
remove the tests in loop.c again.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Infinite loop (bug in wordcode evaluation?)

[Bart Schaefer]

On Jan 31,  1:04pm, Sven Wischnowsky wrote:
} Subject: Re: Infinite loop (bug in wordcode evaluation?)
}
} 
} Bart Schaefer wrote:
} 
} >     function hang() {
} > 	emulate -L zsh
} > 	trap return HUP INT QUIT                                         
} > 	for ((i=0; 1; i=0)) do
} >             tmp=()                                                  
} >             vared -p "Type ^C here: " tmp                       
} >         done                            
} >     }
} > 
} > If you interrupt this with ^C, 3.1.6-dev.16 goes into a loop repeatedly
} > evaluating the "for" expressions on an empty loop body.  The "trap" is
} > important.
} 
} The problem is that none of the functions in loop.c check if retflag
} is set and hence don't return. But this was not changed by the
} wordcode stuff  -- and a older zsh without that I have here behaves
} the same. In fact, I think that zsh behaved this way either always or
} for a long time.

I can't find any loop construct in 3.0.7 that produces this behavior,
yet 3.0.7 does not have any of those extra retflag tests in loop.c.

Does anyone know what else might have changed to cause this problem?
I want to understand it so that I don't leave a bug in 3.0.8.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Infinite loop (bug in wordcode evaluation?)

[Sven Wischnowsky]

Bart Schaefer wrote:

> The following function reproduces the bug in an interactive shell with ZLE
> active:
> 
>     function hang() {
> 	emulate -L zsh
> 	trap return HUP INT QUIT                                         
> 	for ((i=0; 1; i=0)) do
>             tmp=()                                                  
>             vared -p "Type ^C here: " tmp                       
>         done                            
>     }
> 
> If you interrupt this with ^C, 3.1.6-dev.16 goes into a loop repeatedly
> evaluating the "for" expressions on an empty loop body.  The "trap" is
> important.

The problem is that none of the functions in loop.c check if retflag
is set and hence don't return. But this was not changed by the
wordcode stuff  -- and a older zsh without that I have here behaves
the same. In fact, I think that zsh behaved this way either always or
for a long time.


Bye
 Sven

diff -ru ../z.old/Src/loop.c Src/loop.c
--- ../z.old/Src/loop.c	Mon Jan 31 11:35:50 2000
+++ Src/loop.c	Mon Jan 31 12:50:08 2000
@@ -138,6 +138,8 @@
 		break;
 	    contflag = 0;
 	}
+	if (retflag)
+	    break;
 	if (iscond && !errflag) {
 	    str = dupstring(advance);
 	    if (isset(XTRACE)) {
@@ -258,7 +260,7 @@
 		break;
 	    contflag = 0;
 	}
-	if (errflag)
+	if (retflag || errflag)
 	    break;
     }
   done:
@@ -357,6 +359,10 @@
 	    lastval = oldval;
 	    break;
 	}
+	if (retflag) {
+	    lastval = oldval;
+	    break;
+	}
 	execlist(state, 1, 0);
 	if (breaks) {
 	    breaks--;
@@ -364,11 +370,13 @@
 		break;
 	    contflag = 0;
 	}
-	freeheap();
 	if (errflag) {
 	    lastval = 1;
 	    break;
 	}
+	if (retflag)
+	    break;
+	freeheap();
 	oldval = lastval;
     }
     cmdpop();
@@ -410,6 +418,8 @@
 	    lastval = 1;
 	    break;
 	}
+	if (retflag)
+	    break;
     }
     cmdpop();
     popheap();
@@ -447,6 +457,8 @@
 	    run = 1;
 	    break;
 	}
+	if (retflag)
+	    break;
 	s = 1;
 	state->pc = next;
     }
@@ -532,7 +544,7 @@
 	if (pprog && pattry(pprog, word)) {
 	    execlist(state, 1, ((WC_CASE_TYPE(code) == WC_CASE_OR) &&
 				do_exec));
-	    while (wc_code(code) == WC_CASE &&
+	    while (!retflag && wc_code(code) == WC_CASE &&
 		   WC_CASE_TYPE(code) == WC_CASE_AND) {
 		state->pc = next;
 		code = *state->pc;

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de