Re: Bug with traps and exit

["Daniel Shahaf" <d.s@xxxxxxxxxxxxxxxxxx>]

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 <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.
> .....
> > - 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