zsh-workers
 help / color / mirror / code / Atom feed
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: zsh-workers@zsh.org
Subject: Re: Bug with traps and exit
Date: Tue, 17 Dec 2019 07:31:14 +0000	[thread overview]
Message-ID: <20191217073114.sgt4skm3zixuwsfd@tarpaulin.shahaf.local2> (raw)
In-Reply-To: <CAH+w=7ZnBsZJW4ia+PnRTeMBc-5g=dpAVgh84DhuVAfk_52jCQ@mail.gmail.com>

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@daniel.shahaf.name> 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

  reply	other threads:[~2019-12-17  7:33 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-05  7:08 Test release: 5.6.2-test-3 dana
2019-01-05 17:49 ` Peter Stephenson
2019-01-05 18:42   ` dana
2019-01-05 20:58   ` Martijn Dekker
2019-01-05 21:55     ` Daniel Shahaf
2019-01-06  2:37 ` Axel Beckert
2019-01-06 15:12 ` Jun T.
2019-01-06 16:37   ` dana
2019-01-06 16:43     ` Daniel Shahaf
2019-01-06 16:56       ` dana
2019-01-06 21:34     ` Daniel Tameling
2019-01-07  3:25     ` Jun T
2019-01-07  7:02       ` dana
2019-01-21 12:54 ` ETA for zsh 5.7? (was: Test release: 5.6.2-test-3) Axel Beckert
2019-01-21 14:26   ` Peter Stephenson
2019-01-21 19:14     ` Mikael Magnusson
2019-01-21 19:32       ` Mikael Magnusson
2019-01-21 19:32       ` Mikael Magnusson
2019-01-21 21:56         ` Sebastian Gniazdowski
2019-01-22  9:29           ` Peter Stephenson
2019-01-21 23:00 ` Bug with traps and exit Martijn Dekker
2019-11-24  5:54   ` Martijn Dekker
2019-11-25 16:42     ` Sebastian Gniazdowski
2019-12-10 19:23     ` Martijn Dekker
2019-12-11  2:40       ` Daniel Shahaf
2019-12-12 10:14       ` Peter Stephenson
2019-12-13 14:26         ` Martijn Dekker
2019-12-13 14:49           ` Peter Stephenson
2019-12-14 11:28             ` Daniel Shahaf
2019-12-15 18:59               ` Peter Stephenson
2019-12-16  5:24                 ` Daniel Shahaf
2019-12-16  6:37                   ` Bart Schaefer
2019-12-17  7:31                     ` Daniel Shahaf [this message]
2019-12-17 20:29                       ` Peter Stephenson
2019-12-18  0:31                         ` Daniel Shahaf
2019-12-31  2:03                           ` Daniel Shahaf
2019-12-31 13:46                             ` Daniel Shahaf
2019-12-16 10:09                   ` Peter Stephenson
2019-12-16  5:27     ` The bug from workers/44922 (was: " Daniel Shahaf
2020-01-30 13:49       ` The bug from workers/44922 Martijn Dekker
2020-01-30 14:01     ` Bug with traps and exit Martijn Dekker
2020-01-31  4:29       ` Daniel Shahaf
2022-11-26  3:00       ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191217073114.sgt4skm3zixuwsfd@tarpaulin.shahaf.local2 \
    --to=d.s@daniel.shahaf.name \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).