[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PID-reuse races fix, introduced GCC validation brakage
From: |
Yvan Roux |
Subject: |
Re: PID-reuse races fix, introduced GCC validation brakage |
Date: |
Wed, 30 Mar 2016 17:51:35 +0200 |
On 30 March 2016 at 17:37, Christophe Lyon <address@hidden> wrote:
> 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?
it works as expected when it's not a list, it's true
>>>> 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
- PID-reuse races fix, introduced GCC validation brakage, Yvan Roux, 2016/03/30
- Re: PID-reuse races fix, introduced GCC validation brakage, Christophe Lyon, 2016/03/30
- Re: PID-reuse races fix, introduced GCC validation brakage, Yvan Roux, 2016/03/30
- Re: PID-reuse races fix, introduced GCC validation brakage, Christophe Lyon, 2016/03/30
- Re: PID-reuse races fix, introduced GCC validation brakage,
Yvan Roux <=
- Re: PID-reuse races fix, introduced GCC validation brakage, Ben Elliston, 2016/03/30
- Re: PID-reuse races fix, introduced GCC validation brakage, Yvan Roux, 2016/03/30
Re: PID-reuse races fix, introduced GCC validation brakage, Pedro Alves, 2016/03/31
- Re: PID-reuse races fix, introduced GCC validation brakage, Yvan Roux, 2016/03/31
- Re: PID-reuse races fix, introduced GCC validation brakage, Pedro Alves, 2016/03/31
- Re: PID-reuse races fix, introduced GCC validation brakage, Yvan Roux, 2016/03/31
- Re: PID-reuse races fix, introduced GCC validation brakage, Pedro Alves, 2016/03/31
- Re: PID-reuse races fix, introduced GCC validation brakage, Yvan Roux, 2016/03/31
- Re: PID-reuse races fix, introduced GCC validation brakage, Pedro Alves, 2016/03/31
- Re: PID-reuse races fix, introduced GCC validation brakage, Yvan Roux, 2016/03/31