[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/36532 (fix for a core dump in /bin/sh dotrap())
The following reply was made to PR bin/36532; it has been noted by GNATS.
From: Robert Elz <kre%munnari.OZ.AU@localhost>
Subject: Re: bin/36532 (fix for a core dump in /bin/sh dotrap())
Date: Mon, 22 Feb 2016 01:06:20 +0700
I don't have a test case to cause this, but I have a hypothesis about
how it might happen.
If sh just happens to be executing a "trap - N" command when
signal N arrives, then trap[N] will be set to NULL, at the
same time as gotsig[N] (really N-1, but that's irrelevant)
will get set (along with pendingsigs).
When the shell gets to process the pending signal, it assumes that
if trap[N] is NULL, then the signal state for the process is SIG_DFL,
(which it does get set to, but possibly, just a little too late) and
so not eligible for delivery to the shell.)
Assuming this is the cause, then the patch supplied (minus the error()
when trap[N] is NULL - just do nothing in that case, ignore the signal,
it is the best we can do (other than possibly kill(getpid(), N) to
cause the signal to be redelivered, and take its normal default action.
Another way, would be to do the setsig() first (when going to SIG_DFL
or SIG_IGN only - though the SIG_IGN case doesn't cause a problem, there
the trap is just an empty string, which can be processed, doing nothing,
without problems) then process pending signals (if any) and only after we
know that we cannot have signal N delivered, and that there isn't one
pending, then set trap[N] to NULL.
There is no (rational) way to fix this just by reordering the setsig()
and trap[N] = NULL statements, the signal might already be pending,
it could have arrived from any time after the last check of pendingsigs
until the setsig() is eventually done.
Main Index |
Thread Index |