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 488f4514 for ; Mon, 16 Dec 2019 05:25:13 +0000 (UTC) Received: (qmail 6678 invoked by alias); 16 Dec 2019 05:25:07 -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: 45044 Received: (qmail 2816 invoked by uid 1010); 16 Dec 2019 05:25:07 -0000 X-Qmail-Scanner-Diagnostics: from wout1-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.24):SA:0(-2.6/5.0):. Processed in 4.992584 secs); 16 Dec 2019 05:25:07 -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: gggruggvucftvghtrhhoucdtuddrgedufedrvddtgedgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtugfgjggfsehtkedttddtreejnecuhfhrohhmpeffrghn ihgvlhcuufhhrghhrghfuceougdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgvqe enucfkphepjeelrddukedtrdehjedrudduleenucfrrghrrghmpehmrghilhhfrhhomhep ugdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgvnecuvehluhhsthgvrhfuihiivg eptd X-ME-Proxy: Date: Mon, 16 Dec 2019 05:24:23 +0000 From: Daniel Shahaf To: Peter Stephenson Cc: zsh-workers@zsh.org Subject: Re: Bug with traps and exit Message-ID: <20191216052423.svgnhfkpsxh46a6j@tarpaulin.shahaf.local2> References: <3859b4bf-08ba-62d5-f00a-3ec4e67caf95@inlv.org> <1576145690.8441.3.camel@samsung.com> <46f2fc10-2f2c-88f1-e4e2-87196a39a37a@inlv.org> <1576248580.5214.17.camel@samsung.com> <20191214112826.4klmtvxvuhioddcf@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) Peter, Thanks for all the details. I'm afraid there are two distinct bugs being discussed in this thread. One is workers/44922, which you analyzed in detail. I'll follow up about that one with Martijn. However, the bug I was confused about how to get started on is 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. 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? Thanks, Daniel Peter Stephenson wrote on Sun, Dec 15, 2019 at 18:59:21 +0000: > On Sat, 2019-12-14 at 11:28 +0000, Daniel Shahaf wrote: > > Peter Stephenson wrote on Fri, Dec 13, 2019 at 14:49:40 +0000: > > > As you know, getting anyone interested in looking at things is very > > > difficult. I'm taking more of a back seat myself, unless I can see > > > something glaring. Anyone is more than welcome to jump in while > > > the old guard is still looking on to help. > > > > I don't know about others, but I'm not even sure where to begin fixing this. > > I can find the code handling traps easily enough ('intrap', etc), and I know > > where the code handling functions is (doshfunc()), but how to proceed? Would > > the right fix be to add some code in the end of runshfunc(), after > > unqueue_signals(), that checks whether a trap has been executed and called > > 'exit'…? > > OK, so this is deliberately somewhat wordier than if I was just replying > to the message myself, to try to get my thinking across. So please bear > with me. > > Frankly, I'm never sure where to begin fixing *anything* that's not > immediately obvious. The first step in something like this is to > identify key points where things need to happen and may or may not > actually be happening, and then work out whether we're hitting those > points, and if not, why not, and if so, why it's doing something > different there from what it should (which may include setting something > up differently for a future action, in this case on signal delivery). > > > trap 'echo SIGINT; trap - INT; kill -s INT $$; echo woops' INT > > kill -s INT $$ > > > > zsh prints 'woops', but shouldn't. > > Martijn is presumably saying the trap - INT within the trap should reset > it so the interrupt stops the rest of the trap being dlievered. So does > it reset it? Actually, there's some important information below so you > probably don't need to, but what you'd have to do is trace through to > see what's happening on the "trap - INT" on the trap by getting the > shell to stop when it executes the trap command in the signal caught by > the kill. The trap is set by the bin_trap() handler; zhandler() is > called if the shell is handling an interrupt, though not if the > interrupt is set up to kill or suspend the shell or whatever. > > One easy and obvious thing to try is to simplify: > > trap - INT; kill -S INT $$; echo foo > > That doesn't echo "foo"; that's because the INT is delivered > immedately. The shell doesn't exit if it's interactive, but we do get > returned immediately to the command line. > > In fact, to shortcut the investigation, I think the key point here is to > note that the trap is executed inside the signal handler (see the other > recent thread on signal handlers). So we'd expect the "kill -s INT" > inside the trap to be delivered after the first trap has exited. So > that's probably why you get "whoops". So is that really a problem? > You'll have to disucss that with Martijn. Obviously that's not going to > change fundamentally without a complete rewrite, and this looks to me a > rather silly experiment anywawy --- it looks to me like it's abusing the > mechanism to reissue a signal within something designed to handle the > signal and then expect that to do something within that same handler --- > but I don't want to have to go on deciding all this by myself, so feel > free to disagree and discuss further. > > pws >