Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Fwd (potential regression in 5.0.3): Bug#732726: zsh function freeze



I'm now back and looking through the mail, most of which I've already
seen as I managed to get it onto my phone while the network was
networking (it was not just that it was 2G, I think the backhaul was a
woodpecker with a dodgy beak and a morse key it kept missing).

It looks like it was either a good or a bad time for me to be away,
depending whether you're me or Bart.  As far as I can see most of the
stuff has been sorted out, by Bart with assistance.  If there's nothing
to indicate otherwise over the next couple of days I'll make a 5.0.5
with the fixes in at the weekend.

First...

On Sat, 21 Dec 2013 17:34:59 -0800
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> } I think we're forking inside execcmd() after adding pipes[0] to the
> } filelist for thisjob.  This subshell is what's going to form the LHS of
> } the pipeline --- and we entersubsh() which will clear the job table.
> } So I think we need to salvage the filelist from the job table and remove
> } the pipe file descriptors in the danger cases, which I take to be the
> } places where we were handling subsh_close in the old version of the code
> } (where we are handling nested shell constructs of some sort).
> 
> I wondered if that would be necessary, but couldn't ever manage to get
> DPUTS() statements in those two places to print anything, so concluded
> that the issue was in the place that I did patch.
> 
> What concerns me is whether we might be closing too many file descriptors
> if we remove all is_fd entries from filelist at that point, but if that's
> in the parent that's going to do nothing but wait for the child it should
> be OK.

Yes, I don't think there should be too much problem with what we *are*
doing, and the regression test seems fine.

I'm a little bit worried about what we're *not* doing.  The closure is
tied to thisjob.  That's probably better than the previous version where
it was simply signalled by a static, neither associated with the current
job nor with the call hierarchy, but I wonder if we should be closing
even more in the subshell (only); should we, in fact, be closing all
f.d.s associated with pipes now that we're no longer in a shell that has
any interest in them?  Or doesn't this actually cause a problem in
practice?  (We clearly shouldn't be removing files, the other purpose of
the filelist, since that's needed at exactly one point after the final
use --- it might be cleaner having a separate list to emphasise the
different behaviour of files and f.d.s but it's probably not worth the
extra pointer now.)

Anyway, that's for future study (FFS, as a colleague slightly
ambiguously puts it).

pws



Messages sorted by: Reverse Date, Date, Thread, Author