Re: Zsh bug report

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Jul 21,  2:46am, Luke Palmer wrote:
} Subject: Zsh bug report
}
} Zsh 4.0.4 segfaults when given the following input:
} 
} 	mkdir dir && cd dir
} 	( cd .. && rmdir dir && ln -s dir/ dir )
} 	cd ..
} 
} Worth looking into?

It's a simple stack overflow, trying to resolve the looping symbolic link.
Zsh is trying to resolve the symbolic link because it first tried to do an
actual "cd .." and that failed (because the current directory has been
removed), so it then attempts to resolve symlinks in $PWD so that it can
take the head of the resulting path.

Interestingly, "pwd -r" doesn't crash -- but it also doesn't do anything
very useful, simply emitting ".".  More on this in a moment.

None of the "quick fixes" for this problem is satisfactory:

- It could try to detect symbolic loops and punt, but one could always
  devise a case where adding one more symlink to the chain would foil
  the detection algorithm (by exceeding memory limits, not by way of any
  algorithmic shortcoming).  (Yes, a sufficiently clever algorithm could
  make this so difficult as to require several million more monkeys, but
  remember I'm talking about _quick_ fixes.)

- It could limit recursion depth, but one could always devise a case
  where adding one more symlink to a non-looping chain would cause the
  "cd" to fail where it should have succeeded.  Also, "limit stacksize"
  set small enough could always force the fault.

- It could trap the SIGSEGV and keep running (it's annoying that this
  does not generate e.g. SIGSTKFLT instead) but that potentially masks
  other errors from which the shell really can't recover.

- It could simply fail at "cd .." and never try to resolve $PWD.

The right, not quick, fix is the rewrite of bin_cd() and friends that has
nominally been on my todo list for almost three years now.  There's no
reason that "cd" has to have it's own recursive symlink resolver, i.e.,
that it can't use zgetcwd() like bin_pwd() does.  The reason I've never
actually tackled the project is that the CHASE_LINKS and error recovery
logic is so tangled that it'll take quite a while to make sure that the
rewritten code does the same thing as the current code.

Any volunteers to really work over Test/B01cd.ztst so that it's sure to
exercise all the bizarre twists of the current code?

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net