BIG bug!

BIG bug!

[Dave Sainty]

This bug has a very weird effect that could cause a lot of strife! The
effect appears to be that at the end of .'ing a script (including
login scripts), zsh is likely to jump back into the middle of the
script and start again! This causes infinite loops, or weird errors
with no apparent cause (I could not see where the unmatched " was,
because my login script was being jumped into halfway through a line
with a " near the start!)

At the end of the letter is a uuencoded/gzipped script that will show
the bug if "zsh -f script-name"'d. It is my login script with
everything removed that doesn't affect the bug. Also, the exact size
of the file is vital, which is why I'm mailing it as binary. It has a
"return" statement strategically placed in the middle of the script,
that xtrace shows is executed at the end of the script! Magic! :-)
This is visible on Solaris and Alpha/OSF boxes at any rate.

This is new since beta 8. In fact, it seems to be Peter Stephenson's
fault, if I may point the finger... ;-) The fault appears after
applying patch 6160 to exec.c (In which a typo was fixed also by patch
6197, but this does not solve the problem here).

This code does very little new, simply exiting under certain
conditions, so there must be a logic problem in the condition it exits
on. But I don't have a clue what is going on in this code, so I'll
leave it to someone who does. (Peter?)

And yeah.... That did take a lot of hunting! But I have so much work
to do, I was just looking for a reason to procrastinate! :-)

Dave.

Re: BIG bug!

[P.Stephenson]

david.sainty@comp.vuw.ac.nz wrote:
> This bug has a very weird effect that could cause a lot of strife! The
> effect appears to be that at the end of .'ing a script (including
> login scripts), zsh is likely to jump back into the middle of the
> script and start again! This causes infinite loops, or weird errors
> with no apparent cause (I could not see where the unmatched " was,
> because my login script was being jumped into halfway through a line
> with a " near the start!)
> 
> And yeah.... That did take a lot of hunting! But I have so much work
> to do, I was just looking for a reason to procrastinate! :-)

Thanks for the work on this... You'll be gratified/annoyed to know it
only took me a few minutes to track down with the information you
gave.  These are classic symptoms for exit() being called instead of
_exit(), so the culprit had to be the exit for builtins with an exec.
The problem was the new code which allows an exec at the end of a
subshell turns on CFLAG_EXEC, and the forked variable isn't enough to
tell you if you're in a subshell, so I added the explicit test for
`subsh'.

(Translation:  You're likely to get this when doing something like
backtick expansion where the last command was a builtin --- that was
the case in Dave's script.)

Anyway, this disposes of that spurious `return' call on OSF/1 3.0.
If anyone still experiences similar problems, let me know a.s.a.p.
Looking at the exit in execlist(), it may well be that needs the same
treatment.  (The symptoms would then show up when ERREXIT was set in a
subshell which terminated on an error.)

*** Src/exec.c.exit	Mon Jun  5 10:16:00 1995
--- Src/exec.c	Mon Jun  5 10:16:14 1995
***************
*** 1450,1456 ****
  
  	    if (!forked) {
  		if (cmd->flags & CFLAG_EXEC)
! 		    exit(lastval);
  		if (savelist) {
  		    /* Restore variables, freeing the list but not data. */
  		    Savepm savenode;
--- 1450,1459 ----
  
  	    if (!forked) {
  		if (cmd->flags & CFLAG_EXEC)
! 		    if (subsh)
! 			_exit(lastval);
! 		    else
! 			exit(lastval);
  		if (savelist) {
  		    /* Restore variables, freeing the list but not data. */
  		    Savepm savenode;

-- 
Peter Stephenson <P.Stephenson@swansea.ac.uk>  Tel: +44 1792 205678 extn. 4461
WWW:  http://python.swan.ac.uk/~pypeters/      Fax: +44 1792 295324
Department of Physics, University of Wales, Swansea,
Singleton Park, Swansea, SA2 8PP, U.K.