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

[Christophe Lyon]

On 30 March 2016 at 17:28, Yvan Roux <address@hidden> wrote:
> On 30 March 2016 at 17:18, Christophe Lyon <address@hidden> wrote:
>> On 30 March 2016 at 17:03, Yvan Roux <address@hidden> wrote:
>>> Hi,
>>>
>>> https://lists.gnu.org/archive/html/dejagnu/2015-07/msg00000.html
>>>
>>> this patch introduced  a new failure related to GDB testing, but this
>>> time in GCC guality part of the testsuite.  When
>>> gcc/testsuite/gcc.dg/guality/example.c is executed we have this set of
>>> processes started
>>>
>>> PID  PPID     command
>>> 100  99          ./example.exe
>>> 101  99          cat
>>> 102  100        sh -c gdb -nx -nw --quiet > /dev/null 2>&1 ./example.exe
>>> 103  102        gdb -nx -nw --quiet ./example.exe
>>>
>>> The issue is that when close_wait_program is called pid="100 101" and
>>> when the "wait" returns none of these 4 processes is actually killed,
>>> and the killing of the "kill pipeline" made these pids untouched and
>>> the validation hangs forever.
>>>
>>
>> It seems to me that close_wait_program assumes that pid is a number,
>> while it can be list.
>>
>> Or am I mistaken?
>
> yes, that's it, only the first element of the pid list gets the "-"
> for the group pid for instance, but it has no real impact, at least on
> the cases I looked at.  My on-going fix cleans that as well.
>
I meant: what does this do:
if { $pid > 0 }
when pid is actually a list?

>>> I not sure what's the best way to fix this issue without
>>> re-introducing the pid race in GDB.  I'm testing a solution which
>>> first gather all the childs processes of the close_wait_program pid
>>> input (with a recursive call of pgrep -P) and then kill them all with
>>> a -15, my assumption is that killing explicitly all the processes
>>> (maybe in the child -> parent order) will avoid the need of stdin
>>> closing and the pid re-use race, but I might be wrong, and all
>>> comments are welcome.  It works so far on a subset of the testsuite,
>>> but I'm still validating this approach.  Now, maybe just the reducing
>>> the sleeping time might workaround the issue....
>>>
>>> Cheers,
>>> Yvan
>>>
>>> _______________________________________________
>>> DejaGnu mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/dejagnu