From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 30a7308c for ; Wed, 18 Dec 2019 00:32:27 +0000 (UTC) Received: (qmail 6140 invoked by alias); 18 Dec 2019 00:32:22 -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: List-Unsubscribe: X-Seq: 45074 Received: (qmail 6058 invoked by uid 1010); 18 Dec 2019 00:32:22 -0000 X-Qmail-Scanner-Diagnostics: from wout4-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25663. spamassassin: 3.4.2. Clear:RC:0(64.147.123.20):SA:0(-2.6/5.0):. Processed in 0.75464 secs); 18 Dec 2019 00:32:22 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddtkedgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdffrghn ihgvlhcuufhhrghhrghffdcuoegurdhssegurghnihgvlhdrshhhrghhrghfrdhnrghmvg eqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurdhssegurghnihgvlhdrshhhrghhrghf rdhnrghmvgenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-689-g5a57b82-fmstable-20191216v1 Mime-Version: 1.0 Message-Id: <10a2ca98-ae46-4975-93f8-7db835f47690@www.fastmail.com> In-Reply-To: References: <1576145690.8441.3.camel@samsung.com> <46f2fc10-2f2c-88f1-e4e2-87196a39a37a@inlv.org> <1576248580.5214.17.camel@samsung.com> <20191214112826.4klmtvxvuhioddcf@tarpaulin.shahaf.local2> <20191216052423.svgnhfkpsxh46a6j@tarpaulin.shahaf.local2> <20191217073114.sgt4skm3zixuwsfd@tarpaulin.shahaf.local2> Date: Wed, 18 Dec 2019 00:31:27 +0000 From: "Daniel Shahaf" To: "Peter Stephenson" , zsh-workers@zsh.org Subject: Re: Bug with traps and exit Content-Type: text/plain Peter Stephenson wrote on Tue, 17 Dec 2019 20:29 +00:00: > On Tue, 2019-12-17 at 07:31 +0000, Daniel Shahaf wrote: > >Bart Schaefer wrote on Sun, Dec 15, 2019 at 22:37:53 -0800: > >>On Sun, Dec 15, 2019 at 9:25 PM Daniel Shahaf wrote: > >>> > >>> workers/44007 (also in this thread): > >>> > >>>> trap 'printf $1; exit; printf $2' USR1 > >>>> fn() { > >>>> printf 1 > >>>> kill -s usr1 $$ > >>>> printf 2 > >>>> } > >>>> printf 0 > >>>> fn A B > >>>> printf 3 > >>> > >>> Here, Martijn was saying that zsh should print 01A but in fact prints 01A2. > ..... > > - exit_pending is set > > > > - The remainder of the trap is skipped (I assume that's because > > bin_break() set retflag?) > > > > - The remainder of fn() is executed > > I guess this is where the problem is. We should presumably continue to > skip through the function, too. We may be reesetting "breaks" when we > shouldn't be, for example, or failing to propagate some other condition, > perhaps just the effect of the exit_pending. Okay, I'll see if I can find time to trace this further. Might cheat and do . -int retflag; +int retflag_real; +#define retflag (retflag_real || exit_pending) (& have all the places that assign to retflag assign to retflag_real instead) . to smoke test if retflag being reset really is the problem. About 'breaks', it's possible that we overwrite it, too, but in this example 'loops' and 'breaks' should both be zero so that won't be visible. > >> The trouble is that we also have to treat differently the cases of the > >> trap having been set inside the function, and the trap existing > >> outside the function when the function is called. > > > > Why? > > I'm not sure that's necessarily ture of USR1 traps --- I can't think of > why the *effect* would be different, even if the trap is local to the > function --- but one of our big headaches is EXIT traps which in zsh are > triggered at the end of the enclosing context. (An exit in an exit > trap is even worse). Luckily, we don't have to deal with exit traps > in this case, but we do have to be sure we're not doing anything that > will have a knock-on effect there. I'll be happy if there's a 5.8.1 but no 5.8.2. :) Cheers, Daniel