From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5715 invoked by alias); 2 Jan 2014 18:06:20 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 32212 Received: (qmail 10666 invoked from network); 2 Jan 2014 18:06:14 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=QRGJ4w+1ig4BijZVnA/+3cmXsnKzA0kj5ZKnJdv7orI=; b=Evz5cO1W67nVV2D5OwPdhWCV9w93OcB6tsIBebnjqNCwppWdBdH+HxPNUfwBMMI4Df nVQOfomA3Vp90MKolNcU3pM1HszUiFA8H8uB+37bpuE8mt5eAedqkpy4pB5pBrt7A2Iu VmsVaxeaRH8NUFD+dneNvhiQhOhzrhGtT6VGbnSFhDKORLFp48WZJzP3f9Xs/sFSlsSG kiRaqqT372mztFOa/4gukh+oEKuGbcl434EHMN2vZgXftI9KRYgDyF3TXzt2H2bWKTW6 2jXTIYAmTEbSqlalzn8X6JH6QZsgzohZWzAVYbHtrnLG644isvr7JU/1vf9x2Sfhu5Sh Iymw== X-Gm-Message-State: ALoCoQl9Hdxo4xasCBqtClSxpA9oL3tmWeLfiB0JGATDV7ICFylhJKeV/1WkZhENn4vCCU3SMjq6 X-Received: by 10.180.74.230 with SMTP id x6mr55128140wiv.29.1388685971987; Thu, 02 Jan 2014 10:06:11 -0800 (PST) X-ProxyUser-IP: 86.6.157.246 Date: Thu, 2 Jan 2014 18:06:08 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Fwd (potential regression in 5.0.3): Bug#732726: zsh function freeze Message-ID: <20140102180608.6eec4808@pws-pc.ntlworld.com> In-Reply-To: <131221173459.ZM1039@torch.brasslantern.com> References: <20131220192435.GE27889@sym.noone.org> <131220122701.ZM15525@torch.brasslantern.com> <20131220235149.GA21721@xvii.vinc17.org> <20131220235955.GB21721@xvii.vinc17.org> <20131221001235.GC21721@xvii.vinc17.org> <131220181950.ZM15385@torch.brasslantern.com> <131220194223.ZM29152@torch.brasslantern.com> <20131221180846.78a5a013@pws-pc.ntlworld.com> <131221125718.ZM24141@torch.brasslantern.com> <20131221223424.6b7a55a7@pws-pc.ntlworld.com> <131221173459.ZM1039@torch.brasslantern.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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