Re: exec'ing $0 in traps

Re: exec'ing $0 in traps

[Bart Schaefer]

On Feb 17, 12:02pm, Bart Schaefer wrote:
}
} Some combination of the "read" builtin plus calling "exec" from inside
} the signal handler is causing the HUP signal to remain blocked across
} the "exec" -- and re-installing the trap doesn't unblock it.

This affects any process started from a trap -- because the signal
handler blocks the signal while it executes, all childred spawned or
exec'd during the trap will have the trap signal blocked.  E.g. try
this in each of bash and zsh:

    trap 'echo can I interrupt this sleep\?; sleep 10' INT

In bash, two interrupts will print the message and kill the sleep.
In zsh, the message is printed but sleep is immune to interrupts.

However, in both zsh and bash

    trap 'trap "" INT; echo cannot interrupt: sleep 10' INT

result in an uninterruptible sleep after the first interrupt, so it
is also not sufficient to always unblock the signal on execve.

Note this is independent of what signal is used for the trap, I've
reproduced it with HUP, INT, and USR1.

Cleaning all this up seems like something entersubsh() should handle;
proposed patch for that is the first hunk below.

At the same time, install_handler() does not unblock the signal for
which the trap is being created.  This is a lot trickier, because it
isn't clear that

    trap 'echo "in trap"; trap "echo reset trap" INT; sleep 2' INT

is supposed to immediately re-enable HUPs for the parent shell.  In
bash the new signal handler does not run when the sleep is interrupted
but does run subsequently when the parent is interrupted again.

Second hunk below is what I *believe* should cover this, but I'm not
very certain.  Other eyeballs?


diff --git a/Src/exec.c b/Src/exec.c
index 8f4969f..5b9f8d0 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -1068,6 +1068,17 @@ entersubsh(int flags)
     }
     if (!(sigtrapped[SIGQUIT] & ZSIG_IGNORED))
 	signal_default(SIGQUIT);
+    /*
+     * sigtrapped[sig] == ZSIG_IGNORED for signals that remain ignored,
+     * but other trapped signals are temporarily blocked when intrap,
+     * and must be unblocked before continuing into the subshell.  This
+     * is orthogonal to what the default handler for the signal may be.
+     */
+    for (sig = 0; sig < VSIGCOUNT; sig++)
+	if (intrap && sigtrapped[sig] &&
+	    sigtrapped[sig] != ZSIG_IGNORED &&
+	    sig != SIGDEBUG && sig != SIGZERR)
+	    signal_unblock(signal_mask(sig));
     if (!job_control_ok)
 	opts[MONITOR] = 0;
     opts[USEZLE] = 0;
diff --git a/Src/signals.c b/Src/signals.c
index a717677..c1604e3 100644
--- a/Src/signals.c
+++ b/Src/signals.c
@@ -151,6 +151,10 @@ install_handler(int sig)
 #  endif /* SYSV_SIGNALS  */
 # endif  /* BSD_SIGNALS   */
 #endif   /* POSIX_SIGNALS */
+
+    /* ZSIG_IGNORED is OR'd into sigtrapped[sig] while trap in progress */
+    if (!(sigtrapped[sig] & ZSIG_IGNORED))
+	signal_unblock(signal_mask(sig));
 }
 
 /* enable ^C interrupts */

Re: exec'ing $0 in traps

[Bart Schaefer]

On Feb 18,  4:39pm, Bart Schaefer wrote:
}
} This affects any process started from a trap -- because the signal
} handler blocks the signal while it executes, all childred spawned or
} exec'd during the trap will have the trap signal blocked.
} 
} Cleaning all this up seems like something entersubsh() should handle;
} proposed patch for that is the first hunk below.

Better formulation of that follows.

} At the same time, install_handler() does not unblock the signal for
} which the trap is being created.
} 
} Second hunk below is what I *believe* should cover this, but I'm not
} very certain.  Other eyeballs?

Further testing shows this is wrong -- removetrap() has been called to
clear the old trap, so sigtrapped[sig] is always 0 at this point.  The
globals from signals.c don't reliably identify which signals are being
blocked or ignored.  However, some testing reveals another difference:

    (sleep 5 && pkill -USR1 sleep) &
    (trap "" USR1; exec zsh -fc "trap : USR1; exec sleep 20")

For bash [4.2.25], an inner USR1 trap like that does not change ignored
state from the parent shell.  Zsh (any version up to the current one)
restores default handling when adding the inner trap, EXCEPT when
using "trap - USR1" in which case the ignored state is preserved.

In short I don't know what to do upon setting a trap, so I'm going to
leave that for now and settle for fixing the (un)block state in the
subshell.

diff --git a/Src/exec.c b/Src/exec.c
index 8f4969f..aea9d0e 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -975,9 +975,8 @@ entersubsh(int flags)
     int sig, monitor, job_control_ok;
 
     if (!(flags & ESUB_KEEPTRAP))
-	for (sig = 0; sig < VSIGCOUNT; sig++)
-	    if (!(sigtrapped[sig] & ZSIG_FUNC) &&
-		sig != SIGDEBUG && sig != SIGZERR)
+	for (sig = 0; sig < SIGCOUNT; sig++)
+	    if (!(sigtrapped[sig] & ZSIG_FUNC))
 		unsettrap(sig);
     monitor = isset(MONITOR);
     job_control_ok = monitor && (flags & ESUB_JOB_CONTROL) && isset(POSIXJOBS);
@@ -1068,6 +1067,18 @@ entersubsh(int flags)
     }
     if (!(sigtrapped[SIGQUIT] & ZSIG_IGNORED))
 	signal_default(SIGQUIT);
+    /*
+     * sigtrapped[sig] == ZSIG_IGNORED for signals that remain ignored,
+     * but other trapped signals are temporarily blocked when intrap,
+     * and must be unblocked before continuing into the subshell.  This
+     * is orthogonal to what the default handler for the signal may be.
+     *
+     * Start loop at 1 because 0 is SIGEXIT
+     */
+    for (sig = 1; sig < SIGCOUNT; sig++)
+	if (intrap && sigtrapped[sig] &&
+	    sigtrapped[sig] != ZSIG_IGNORED)
+	    signal_unblock(signal_mask(sig));
     if (!job_control_ok)
 	opts[MONITOR] = 0;
     opts[USEZLE] = 0;