From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28494 invoked by alias); 17 Jul 2013 07:00:54 -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: 31523 Received: (qmail 5687 invoked from network); 17 Jul 2013 07:00:49 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <130717000027.ZM15643@torch.brasslantern.com> Date: Wed, 17 Jul 2013 00:00:27 -0700 In-reply-to: <20130716215540.22d88a27@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: bug with eval, proc-subst and pipes" (Jul 16, 9:55pm) References: <20130715133525.GA7694@chaz.gmail.com> <130715100624.ZM14123@torch.brasslantern.com> <20130716215540.22d88a27@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: bug with eval, proc-subst and pipes MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jul 16, 9:55pm, Peter Stephenson wrote: } } On Mon, 15 Jul 2013 10:06:24 -0700 } Bart Schaefer wrote: } > } > It's a race condition of some kind. I can reproduce reliably with } > } > % (){ sleep 5; paste "$@" } <(echo 1) } > } > even without an "eval". } } That's not a race; it looks like it because it relies on a command } running before the one that's using the command substitution, but in } fact the bug in this case is completely deterministic. It may therefore } be a different problem from Stephane's. I don't think so, fundamentally. The problem in both cases is that the file descriptor for the process substitution is closed before the data is read. This has the unintended side-effect of removing the special device file. The reasons for the premature descriptor close may be different, but the end result is the same; I believe fixing either one would fix both. If, instead, a fifo file created by zsh itself is used, it's not removed until the associated job is deleted from the job table. } At line 2864 of exec.c, as it's in the function that's calling sleep, } it closes all the file descriptors of type FDT_PROC_SUBST that it } thinks are private to the sleep. Unfortunately as fdtable is global } it has no way of knowing that actually fd 11 is associated with the } current function, not the sleep, so it closes it anyway. I think you've just explained why simply moving the closem() call is not sufficient. } I suppose a smarter way of marking such file descriptors is needed, } perhaps one associated with the appropriate job in the same way as } auxiliary processes are remembered. Good luck avoiding leaks... Not in the way auxiliary processes are remembered; in the way temporary files are remembered. With #undef PATH_DEV_FD, zsh seems to do a very good job of cleaning up those FIFOs.