Ticket #7229 (new bug)
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||Difficulty:||Unknown|
|Test Case:||Blocked By:|
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).
- waitForProcess attempts to give the signal in the exit code, but the underlying C function doesn't use the WTERMSIG macro. 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 getProcessExitCode is 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 ECHILD is, 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.