Detecting if a process was killed by a signal is impossible
|Reported by:||benmachine||Owned by:|
|Keywords:||Cc:||andersk@…, anton.nik@…, dcoutts|
|Type of failure:||None/Unknown||Test Case:|
|Related Tickets:||Differential Rev(s):|
Currently there is no good way of detecting if a process was terminated by a signal. We have the following problems:
- Firstly, the API doesn't make any allowance for it. This may be because the concept doesn't exist on Windows, I'm not sure. But since the concept does exist on POSIX, we do have to make a decision about what to do there (or if we have made one, document it).
waitForProcessattempts to give the signal in the exit code, but the underlying C function doesn't use the
WTERMSIGmacro. It so happens that on my system it works fine anyway, but it has no right to in principle (and in any case, what it does is both sub-optimal (in that getting killed by SIGINT is indistinguishable from returning 3) and undocumented).
- The C function
getProcessExitCodeis much worse. When a process has exited due to a signal, it tests
WIFSIGNALED, and if true, sets
errno = EINTR(huh?) and returns
-1. Since it is called from
throwErrnoIfMinus1Retry, the result is that it immediately gets called again: but this time the child doesn't exist anymore. The behaviour in the case of
ECHILDis, bizarrely, to pretend that there was a child and it exited with status 0, i.e. success. Which is just untrue.
I don't know what the right behaviour is, but the above is both inconsistent and unhelpful. The lack of
WTERMSIG is easily fixed, but that's the least of the problems here: we really need to work out what ought to happen before we start making it happen.