Re: Bug with traps and exit

[Daniel Shahaf <d.s@daniel.shahaf.name>]

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
>