Re: bin/36532 (fix for a core dump in /bin/sh dotrap())

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/36532; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
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.
 
 kre