Re: Bash 4.3 no longer handles traps when reading input with read

[konsolebox]

On Mon, Oct 14, 2013 at 2:29 AM, Chet Ramey <chet.ramey@case.edu> wrote:

> On 10/11/13 6:19 PM, konsolebox wrote:
> > On Fri, Oct 11, 2013 at 10:06 PM, Chet Ramey <chet.ramey@case.edu
> > <mailto:chet.ramey@case.edu>> wrote:
> >
> >     The SIGCHLD handler was particularly bad, since children can die and
> >     interrupt
> >     the shell at any time.  As an example, glibc uses internal locks
> >     extensively, especially within its malloc implementation, and
> running trap
> >     handlers when a signal arrives (or worse, longjmping back to saved
> state)
> >     caused deadlocks.
> >
> >     The bash signal and trap handling is now much closer to the Posix
> model:
> >     minimal work done when the signal arrives, traps run when it is safe
> to
> >     do so.  If the arriving signal causes certain system calls to return
> >     -1/EINTR, for example if a SIGINT interrupts read(2), bash will
> notice and
> >     check for pending traps.  SIGCHLD doesn't behave like that.
> >
> >
> > Thanks for the reply.
> >
> > I understand the possible effect of receiving multiple signals at once,
> but
> > how are other signals different from it? If one would trap signals like
> > SIGQUIT, SIGABRT, SIGINT, SIGHUP and SIGTERM for safe exitting of an
> > interactive script e.g. during shutdown some of those signals could
> arrive
> > quickly as well.
>
> It's not a question of receiving multiple signals at once.  It's a question
> of running too much in a signal handler.  Since Posix says you can only do
> a certain small number of things in a signal handler, bash needs to do as
> little as possible -- for both trapped signals and ones bash handles
> internally -- and defer the real work until it's `safe'.  In the case of
> traps, this is generally at command boundaries.
>
> Bash-4.3 handles signals and traps when a read run by the read builtin is
> interrupted by a  signal.  I'm not  sure that's the best thing to do,
> since traps should really be run when commands finish, but we're going to
> try it.
>
> Since bash-4.2, bash has installed its SIGCHLD signal handler with
> SA_RESTART, so a child death does not unexpectedly interrupt system calls.
> There were several bug reports concerning this.  So yes, SIGCHLD is
> special.


I'm not really able to comprehend the significance of SA_RESTART to SIGCHLD
that it could affect the signal and make it behave differently from the
other signals i.e. it can't be a good idea to allow interruption from it
when in a read builtin context, but could it be possible that we allow it
when not in posix mode? Probably it's about the variable posixly_correct.
If we can allow at least just one interruption to happen maybe with the
help of the variable running_trap it would really be good enough.