signal weirdness

signal weirdness

[Zefram]

I got these results on Solaris 2.5.1 and SunOS 4.1.4, not tested
anywhere else.

Create a program called "segv", from this source or something equivalent:

main() { *(volatile char *)0 = 1; }

(I.e., the program will die with a SIGSEGV.)

Run the script:

trap 'echo SIGSEGV' SEGV
foo=$(segv)
echo finished
exit 0

When the segv program terminates, zsh acts as if it had received a
SIGSEGV (it executes the trap), despite the fact that it was its child
process that received it.  This doesn't happen if the signal is not
trapped.

The same happens if the command is run directly, rather than being
within $().

I'm not looking into this at the moment; I'm not familiar with the
signal code, and I have more urgent things to do.  I hope someone can
diagnose this.

-zefram

Re: signal weirdness

[Bart Schaefer]

On Nov 13,  2:06pm, Zefram wrote:
} Subject: signal weirdness
} 
} When the segv program terminates, zsh acts as if it had received a
} SIGSEGV (it executes the trap), despite the fact that it was its child
} process that received it.  This doesn't happen if the signal is not
} trapped.
} 
} I'm not looking into this at the moment; I'm not familiar with the
} signal code, and I have more urgent things to do.  I hope someone can
} diagnose this.

Around line 180 in jobs.c:

    /* WHY DO WE USE THE RETURN STATUS OF PROCESS GROUP LEADER HERE? */
    /* If the foreground job got a signal, pretend we got it, too.   */
    if (inforeground && WIFSIGNALED(status)) {
        if (sigtrapped[WTERMSIG(status)]) {
            /* Run the trap with the error flag unset.
             * Errflag is set in printjobs if the jobs terminated
             * with SIGINT.  I don't know why it's done there and
             * not here.   (PWS 1995/06/08)
             */
            errflag = 0;
            dotrap(WTERMSIG(status));
            /* We keep the errflag as set or not by dotrap.
             * This is to fulfil the promise to carry on
             * with the jobs if trap returns zero.
             * Setting breaks = loops ensures a consistent return
             * status if inside a loop.  Maybe the code in loops
             * should be changed.
             */
            if (errflag)
                breaks = loops;
        } else if (WTERMSIG(status) == SIGINT ||
                   WTERMSIG(status) == SIGQUIT) {
            breaks = loops;
            errflag = 1;
        }

This code is intended to handle (among other things) the case where the
user types the interrupt character when a foreground job is executing,
thereby causing zsh to behave the same as if interrupt were typed at a
bare prompt.  Similarly, if the user typed the quit character, or if
the foreground job got a HUP because the tty line dropped, we want zsh
to notice and behave as if it got the signal as well.  But (except for
INT and QUIT), the signals are only interesting if they're trapped, as
zsh normally ignores the rest.

I don't know who wrote the "WHY DO WE ..." question, and I'm not sure
exactly what's being asked.  Why is it the group leader's status?  Or
why is it the status at all?  It's the group leader because the group
leader gets the tty-generated signals, and it's the status because the
type of signal received by the job can be extracted from the status.

Anyway, the code is more general than it needs to be -- there is only
a subset of signals (HUP, INT, QUIT, TSTP, ...) that really need to be
handled this way.  On the other hand, there's no way to make a good
comprehensive cross-platform list of all the signals that should be so
treated, which is why it's as general as it is.  It might be possible
to come up with a list of signals that we know should *not* be treated
this way (BUS, FPE, SEGV, others?) and explicitly omit them, if this
is really annoying for some reason.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

Re: signal weirdness

[Zefram]

>    /* If the foreground job got a signal, pretend we got it, too.   */

Oh.

>This code is intended to handle (among other things) the case where the
>user types the interrupt character when a foreground job is executing,
>thereby causing zsh to behave the same as if interrupt were typed at a
>bare prompt.  Similarly, if the user typed the quit character, or if
>the foreground job got a HUP because the tty line dropped, we want zsh
>to notice and behave as if it got the signal as well.  But (except for
>INT and QUIT), the signals are only interesting if they're trapped, as
>zsh normally ignores the rest.

I don't see the problem with just ignoring the situation, in the case
of key-generated interrupts.  If the user wants to kill a program *and*
have the shell process a SIGINT handler, e can press ^C twice.  HUP is
the only one that we really need to handle specially.

>Anyway, the code is more general than it needs to be -- there is only
>a subset of signals (HUP, INT, QUIT, TSTP, ...) that really need to be
>handled this way.  On the other hand, there's no way to make a good
>comprehensive cross-platform list of all the signals that should be so
>treated, which is why it's as general as it is.

Shouldn't it be only INT, QUIT and HUP?  I can't see any others that
could justifiably be treated this way.

>                                                 It might be possible
>to come up with a list of signals that we know should *not* be treated
>this way (BUS, FPE, SEGV, others?) and explicitly omit them, if this
>is really annoying for some reason.

It is very annoying.  It seems like the shell is going out of its way
to cause inconvenience: without that code it would be easy to
distinguish between an external program crashing and the shell
crashing.

What does POSIX say about all of this?

-zefram

Re: signal weirdness

[Bart Schaefer]

On Nov 13,  6:03pm, Zefram wrote:
} Subject: Re: signal weirdness
}
} I don't see the problem with just ignoring the situation, in the case
} of key-generated interrupts.  If the user wants to kill a program *and*
} have the shell process a SIGINT handler, he can press ^C twice.  HUP is
} the only one that we really need to handle specially.

Csh, at least, invokes its onintr handlers when any process spawned from
a csh script gets a keyboard interrupt.  /bin/sh (pre-POSIX, at least)
invokes its INT traps on a single interrupt, AFAIK.

Sometimes the shell is in a loop spawning jobs too fast for pressing ctrl-C
twice to have the desired effect.  What good is an INT handler if zsh never
gets the signal?

} What does POSIX say about all of this?

I'd be interested, too.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern