Re: Bug with traps and exit

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote on Sun, Dec 15, 2019 at 22:37:53 -0800:
> On Sun, Dec 15, 2019 at 9:25 PM Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> 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 : <incumbent value>)?

Cheers,

Daniel