From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10718 invoked by alias); 3 Oct 2014 08:58: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: 33341 Received: (qmail 15103 invoked from network); 3 Oct 2014 08:58:09 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f4-b7f156d0000063c7-f5-542e651d237a Date: Fri, 03 Oct 2014 09:58:04 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Crash Re: Trial for 5.0.7 Message-id: <20141003095804.747476c7@pwslap01u.europe.root.pri> In-reply-to: <141002215856.ZM14108@torch.brasslantern.com> References: <20141002204012.0b884f9c@pws-pc.ntlworld.com> <141002192649.ZM13746@torch.brasslantern.com> <141002203324.ZM13856@torch.brasslantern.com> <141002215856.ZM14108@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42I5/e/4VV3ZVL0Qg73NqhYHmx8yOTB6rDr4 gSmAMYrLJiU1J7MstUjfLoErY/atZ+wFNyUq5myYztjA+FW4i5GTQ0LARGLmh12MELaYxIV7 69m6GLk4hASWMkpsX7uKFcJZziTR1/QCrIpFQFXi4+8fTCA2m4ChxNRNs8HiIgLiEmfXnmcB sYUF1CS+fN8CVMPBwStgLzHrrSlImFPASuL5xW2MEDNPMko0nF/PCpLgF9CXuPr3ExPEFfYS M6+cAZvJKyAo8WPyPbCZzAJaEpu3NbFC2PISm9e8ZZ7AKDALSdksJGWzkJQtYGRexSiaWppc UJyUnmuoV5yYW1yal66XnJ+7iREShF92MC4+ZnWIUYCDUYmH9+MN3RAh1sSy4srcQ4wSHMxK Iryn4/RChHhTEiurUovy44tKc1KLDzEycXBKNTAy8UQJKaXF5H1asID37qVtW1ZzlafvyTsW rzDTcNP+0hfb2W5NlVw9b9oBu4k9F9Qslvs+67C71P/ng6A+X+TUjT5a3zcZuE6VNWTfz6d0 NOyZe8TnYwu21Ftmv5yxadOyY0+rDVJFGp7ayCzwLtM9n2d6N1Xw0qwK6SPr93VVRuvHxbIX WWxQYinOSDTUYi4qTgQA6ag5gSACAAA= On Thu, 02 Oct 2014 21:58:56 -0700 Bart Schaefer wrote: > On Oct 2, 8:33pm, Bart Schaefer wrote: > } > } git-bisect says this is the bad revision: > } > } commit 8189e12312ede991827efc6683b7ce8463deb0bf > } > } 32552 (updated by 32560): fix segfault when using process substitution in > } anonymous function argument list > } > } Also disallow process substitution in function name position. > > OK, I've narrowed it down to the parse.c hunks of the patch. Remove > just that change, and the crash on piping to an anonymous function is > fixed, but this test fails: > > ./C04funcdef.ztst: starting. > Test ./C04funcdef.ztst failed: bad status 1, expected 0 from: > () (cat $1 $2) <(print process expanded) =(print expanded to file) > Error output: > (eval):1: process substitution <(print process expanded) cannot be used here > Was testing: Process substitution with anonymous functions > ./C04funcdef.ztst: test failed. > > Here's the patch to revert workers/32552 (parse.c). I haven't figured > out why fiddling with *complex here mangles the wordcode, some help is > appreciated. Obviously the above test needs to pass. (I presume that *is* an anonymous function, I'd forgotten that functions could be defined with parentheses for the bodies. Presumably using braces makes no difference, though?) The only effect of setting *complex should be instead of going through execsimple(), which is used for ultra trivial cases, the execution of the parsed shell code goes through the main path starting with execlist() and ending up in execcmd() where the expansions are done. What's simple enough not to need the complex flag isn't written down anywhere; it's just controlled by whatever execsimple() can actually cope with. I believe anything involving a pipeline has to be complex, so that may be what you're running into in the crash you originally had. So restoring a complex flag for that case is probably the right thing to do (but I'm saying all this without having actually looked). The error message you're now getting ("process substitution cannot be used here") comes when you go down the execsimple() path, which doesn't have all the infrastructure for jobs. Prima facie your change actually makes it more likely things are treated as complex. Somehow that failing code is being marked as simple with the change (reversion of parse.c), though. I think that's the thing to focus on. Part of the problem here may be that functions (including anonymous functions) make things more complicated because we have two sets of commands that may or may not be simple: the command line, and the code from the function. The arguments to an anoymous function are a particularly unusual case, and it's probably here the issues with complex are arriving, i.e. the command line rather than the function contents. In other words, the issue above is to do with whether complexities in the arguments of the anonymous function correctly cause the complex flag to be set. I suspect I could have put that more simply at half the length. pws