From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17166 invoked from network); 1 Sep 2008 20:25:08 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 1 Sep 2008 20:25:08 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 2125 invoked from network); 1 Sep 2008 20:25:00 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 1 Sep 2008 20:25:00 -0000 Received: (qmail 15720 invoked by alias); 1 Sep 2008 20:24:51 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25589 Received: (qmail 15698 invoked from network); 1 Sep 2008 20:24:49 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 1 Sep 2008 20:24:49 -0000 Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.179]) by bifrost.dotsrc.org (Postfix) with ESMTP id 0F52C801E2B4 for ; Mon, 1 Sep 2008 22:24:35 +0200 (CEST) Received: by ik-out-1112.google.com with SMTP id c28so883828ika.5 for ; Mon, 01 Sep 2008 13:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=NvAnmZV5Cx68kcqvlRwRAWbAM1QddECyNLOsv7dVx+4=; b=L7etW/T5gRH6ePhmxlVc94TPIyUcyA3blhr6bK1dAsV+PXfMAHHxSsCgAVgztbdz4u TUCNE4sbmFW0s6aVtcgTc5tNMjMEygh/AX/sU4A237N0+AB+3sgiyEK7jIo6+7L2mvzY T6cJEWop4D3gN2q2QTBPhUgLcWCJzTFsmH/F8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=L9z7FTol2m6nSPfbir/XMsguYBPkXSvnr1X837R2kJuWtsZT+T5SNfbFSXNkkh7cSS 4ei9IipGNVVdq3ApC30SuRV8svDMMb25OyB0Z4kqWJsytqu0DS/wYOR/cCKhxIFo4Kkd OsI5oDbOacPZJ9pojogj8zZdO+aEVR9HmkTxs= Received: by 10.210.50.5 with SMTP id x5mr7012302ebx.181.1220300674809; Mon, 01 Sep 2008 13:24:34 -0700 (PDT) Received: by 10.210.73.14 with HTTP; Mon, 1 Sep 2008 13:24:34 -0700 (PDT) Message-ID: <237967ef0809011324o173c11f4h501570fd9814e22e@mail.gmail.com> Date: Mon, 1 Sep 2008 22:24:34 +0200 From: "Mikael Magnusson" To: zsh-workers Subject: Re: Segfault on =() expansion In-Reply-To: <20080901211320.11be3dbd@pws-pc> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <237967ef0808310139x4031c054pe69360823916bd54@mail.gmail.com> <20080901211320.11be3dbd@pws-pc> X-Virus-Scanned: ClamAV 0.92.1/8131/Mon Sep 1 15:33:22 2008 on bifrost X-Virus-Status: Clean 2008/9/1 Peter Stephenson : > On Sun, 31 Aug 2008 10:39:35 +0200 > "Mikael Magnusson" wrote: >> I could reproduce this on all my remote ssh shells, ranging from 4.2.3 >> to my local current cvs. >> >> % a==(echo foo); : & cat $a >> [1] 14645 >> foo >> % >> [1] + done : >> % a==(echo foo); : & cat $a >> zsh: segmentation fault zsh -f > > This was quite involved (yes, I know, just for once...) Working backwards, I am somehow not overly surprised by this :). > 1. In the second assignment, the list node's data was NULL. This shouldn't > happen, so caused the crash when processing it as a string. > 2. The data was NULL because =(...) expansion failed. > 3. That failed because "thisjob" was -1. > 4. thisjob was -1 for two reasons. > a. It didn't get set for the current job because the current command was > parsed as "simple", so it went through execsimple(), missing out a > lot of steps including all job handling. > b. In this case, the execution of the background job had reset thisjob > to -1. That's why it didn't happen the first time. > 5. The assignment was parsed as simple because all assignments are. > "Simple" means everything happens entirely in the shell and won't > use job handling: this isn't true here because process substitutions > need to have a job to attach the temporary file to. > > The fixes are: > to 5: assignments with process substitutions can't be simple. > to 2: on failure of process substitutions (and others) set the data to > an empty string. > > (I wonder, actually, if 4b. needs unfixing, i.e. thisjob should be made to > default to -1.) > > This will cause the "cat" in the test to give an error. This is the > correct behaviour: the file generated by the =(...) substition is a > temporary file (this is clearly documented) that only lasts for the > length of the current command, which is just the assignment. So > actually process substitutions aren't useful for assignments, which is > probably why this hasn't shown up before. Right, that's what i wanted to confirm just seconds before finding the bug, I was quite surprised to find the temp file hadn't been deleted, though in my case it was sort of what i wanted :). (what i want can also be achieved with a shell function, i'm just very lazy). > I thought about being safe and detecting $(...)'s, too, but that caused this: > > myfd=99 > (echo >&$myfd) 2>msg > bad_fd_msg="${$( > to return a non-zero status. That's because when assignments are > handled by execcmd() rather than execsimple() we don't set the status > for the command, so it retains the previous status. I've fixed that, > but in the end I decided just to restrict the fix to 5. to process > substitution since we'd know by now if it was necessary for command > substitution. -- Mikael Magnusson