From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16143 invoked by alias); 26 Feb 2017 20:29:38 -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: 40652 Received: (qmail 28729 invoked from network); 26 Feb 2017 20:29:38 -0000 X-Qmail-Scanner-Diagnostics: from park01.gkg.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(205.235.26.22):SA:0(0.5/5.0):. Processed in 0.903416 secs); 26 Feb 2017 20:29:38 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: SRS0=ySy1=2H=brasslantern.com=schaefer@bounces.park01.gkg.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at bounces.park01.gkg.net does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at gkg.net Authentication-Results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=brasslantern-com.20150623.gappssmtp.com X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=5BvrANGssS71hT15joauVOHOm4KqiNsQ1eXPms2hRLw=; b=qVZ1Z5Y/wZNNPI2ufyUz4PLRkd4RcrJdcZyX01q6raQUkNb88C92kgwdbwmxId+UXa JMzpKkt4zohd2rruWHXAeJeInevNlKLJOGVgbW0lwc6ModZqir7eeZQOZg1L6h3w4AJ3 XTX6ezXUeHqLA50Lxe2lL1N+m6+ZhVe96dbovyGsBYD7Ec+HqgL/LSd/Z/+tw/DMDgoU osuviGLal1oslXYZcwrRCXewl/ggdGvfn4sMjughzJBs567SDc0PhXZOqkP+cjcnGDy9 TKmdiFGq0+2nUU3+qGlLZgm/5UzuCm4J5d3r2iej3VyI8htnYERCqT9CbYnqNCi1Cy8V spZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=5BvrANGssS71hT15joauVOHOm4KqiNsQ1eXPms2hRLw=; b=c/WT+Atu/O4JIRSWuFvDR1TJlox3max/QlF77nmUntlID7f/A5aOLDAkyic4QRw8/Y q6IrRwNs629YROi4BhRZe2y0zDCE3l3iCOVbIp+zlXuUwTwUVvGTIvd2fbUeNDx5iODx IAkNI7LAC+YPr1wc8ImJ2VeyyudRqZ1pEmVrmhinEZFO5u/GDkPec4W2Na3G97L6pdXd 5+bjl+iQokHQVdzRlQzz3p3+RwhuD0ljJriXzH+kF5wt2QTOzmWS1NBJeewAMjKD3oq3 qI7FAoCsP3vWHizEB4jl8d+LBmYlp4h3rU/aelVB/OZOUH1A3P0L3QxDxLXQaicaj00h sivg== X-Gm-Message-State: AMke39moMM3W8HkHYXvCM8tae1n/F2bdlqz8V1eT5LkqeK6GuUwfq4SVX9fbViGyx9UdSg== X-Received: by 10.176.82.165 with SMTP id v34mr6018252uav.133.1488140948643; Sun, 26 Feb 2017 12:29:08 -0800 (PST) From: Bart Schaefer Message-Id: <170226122919.ZM4443@torch.brasslantern.com> Date: Sun, 26 Feb 2017 12:29:19 -0800 In-Reply-To: <5258197e-1903-b188-f033-fc424a271077@inlv.org> Comments: In reply to Martijn Dekker "[BUG] Solaris-specific program flow corruption after subshell error exit" (Feb 26, 6:36am) References: <5258197e-1903-b188-f033-fc424a271077@inlv.org> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Martijn Dekker , Zsh hackers list Subject: Re: [BUG] Solaris-specific program flow corruption after subshell error exit MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Feb 26, 6:36am, Martijn Dekker wrote: } } In the course of that testing I've come across a zsh bug that *only* } manifests on Solaris, at least version 11.3. (A free VirtualBox VM for } evaluation purposes is available from Oracle.) } } If a subshell exits due to an error in a special builtin or redirection, } execution flow is corrupted in such a manner that, when end of file is } reached without an explicit 'return' or 'exit' being encountered, } execution of the file does not end but restarts at the point exactly } after the subshell was exited. The second time around, if program } specifics allow it, execution ends normally. Given that this is specific to Solaris and has to do with execution of script files, I'm going to guess that it's related to file descriptor management and buffering within STREAMS modules. In particular I'm guessing that the POSIX-compatible behavior referenced at the "fatal:" label in exec.c near line 4000 is leaving some kind of shared stdin state between the parent and the subshell, because "set" is a special builtin so will invoke the exit at that point. Without actually running the code, I'd expect we're going through the _exit() branch rather than the exit() branch which under normal circumstances is deliberately to avoid having such shared state mess up the parent file descriptor positions, but maybe that's not sufficient. Whether this is revealing a bug in zsh or a bug in Solaris 11.3 I can't say.