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 bb6059bc for ; Tue, 17 Dec 2019 07:33:20 +0000 (UTC) Received: (qmail 18243 invoked by alias); 17 Dec 2019 07:31:57 -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: 45060 Received: (qmail 29450 invoked by uid 1010); 17 Dec 2019 07:31:57 -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 4.638433 secs); 17 Dec 2019 07:31:57 -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: gggruggvucftvghtrhhoucdtuddrgedufedrvddtiedguddtlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtugfgjggfse htkedttddtreejnecuhfhrohhmpeffrghnihgvlhcuufhhrghhrghfuceougdrshesuggr nhhivghlrdhshhgrhhgrfhdrnhgrmhgvqeenucfkphepjeelrddukedtrdehjedruddule enucfrrghrrghmpehmrghilhhfrhhomhepugdrshesuggrnhhivghlrdhshhgrhhgrfhdr nhgrmhgvnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Date: Tue, 17 Dec 2019 07:31:14 +0000 From: Daniel Shahaf To: zsh-workers@zsh.org Subject: Re: Bug with traps and exit Message-ID: <20191217073114.sgt4skm3zixuwsfd@tarpaulin.shahaf.local2> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) 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. > > Have a look at the "shell_exiting" global manipulated in builtin.c. Okay, so as far I can tell, the flow is: - fn() called - signal sent - signal received - trap called - exit called - zexit(ZEXIT_DEFERRED) called, and returns immediately + Note: shell_exiting is NOT incremented, because the || condition in zexit() short circuits - 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 - At the end of doshfunc(), exit_pending is tested and zexit(ZEXIT_NORMAL) is called I have not verified every single detail here in the debugger, but hopefully I'm not too far off the mark. So, I'm still not sure what to do... but I'm guessing that when execution of the trap ends, something-or-other clears retflag, so the 'list' that's the body of fn() continues execution? Does this sound about right? > (Some comments still refer to "in_exit" which IIRC was replaced by > "shell_exiting".) It was one comment. I've updated it. > > This suggests the 'exit' inhibits «printf $2» and «printf 3» from running, but > > doesn't inhibit «printf 2» (without a dollar sign) from running. How would > > you approach something like this? I'm guessing bin_exit should set a global > > volatile int variable to '1' if it's called from a signal handler, but where > > would that variable be checked? > > Note that "from_where" in zexit() already indicates whether we are > coming from a signal, but bin_break (which handles BIN_EXIT) does not > treat "in a signal handler" as "coming from a signal" when calling > zexit(). This is why the function continues running -- zexit() passes > from_where = 2 ("can't actually exit yet"), I suspect in order to > allow running an EXIT trap set by the function itself. > > 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? > Trivially treating exit from a handler the same as being killed by signal > whose default behavior is to exit, leads to failures in the test suite. Could you show the patch you tested here (even though it doesn't work)? Did you make bin_break() call zexit(…, intrap ? ZEXIT_SIGNAL : )? Cheers, Daniel