Re: PID-reuse races fix, introduced GCC validation brakage

On 31 March 2016 at 19:35, Pedro Alves <[email protected]> wrote:
> On 03/31/2016 04:25 PM, Yvan Roux wrote:
>> Hi Pedro,
>>
>> On 31 March 2016 at 16:20, Pedro Alves <[email protected]> wrote:
>
>> The regression is due to this part:
>>
>> +    # Reap it.
>> +    set res [catch "wait -i $program_id" wres]
>> +    if {$exec_pid != -1} {
>> +       # We reaped the process, so cancel the pending force-kills, as
>> +       # otherwise if the PID is reused for some other unrelated
>> +       # process, we'd kill the wrong process.
>> +       exec sh -c "exec > /dev/null 2>&1 && kill -9 $exec_pid"
>> +    }
>>
>> In our case the "wait -i" command ends without any effect on the
>> running processes
>
> "wait" just reaps an already zombie process.  So if that returns,
> $program_id either already exited and is zombie, or wait
> returned an error.
>
>> and then it kills the command which was about to
>> kill them, and the validation is stuck.
>>
>
> So before my patch, the "wait -i" would also return immediately,
> but it just happened that the "kill -15 $pgid" etc. commands kept
> running in the background and ended up killing the processes
> after the 5 / 10 seconds sleeps.  Correct?

Yes, that's correct the processes are killed when it's SIGKILL turn.

> How come the "wait -i" returns before _any_ process is
> dead/zombie, as you say?  Did wait return an error?
> I suspect that's something to do with taking the open path
> instead of spawn, due to redirection.
>
> And I wonder why the "kill -2 $pgid | kill -2 $pid" command didn't
> cause "cat" to exit?

So, when I look in /proc/<pids>, the status of the 2 processes are:
example.exe : tracing stop
cat : zombie
and the wait return value is 0