Zsh Mailing List Archive
Messages sorted by:
Re: Zsh bug report
- X-seq: zsh-workers 17471
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: Luke Palmer <fibonaci@xxxxxxxxxxxxxxxxxxxxxxx>, <zsh-workers@xxxxxxxxxx>
- Subject: Re: Zsh bug report
- Date: Sun, 21 Jul 2002 17:42:31 +0000
- In-reply-to: <Pine.LNX.4.33.0207210240110.2396-100000@xxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <Pine.LNX.4.33.0207210240110.2396-100000@xxxxxxxxxxxxxxxxxxxxxxx>
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
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
Messages sorted by: