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

[Yvan Roux]

On 31 March 2016 at 21:27, Pedro Alves <address@hidden> wrote:
> On 03/31/2016 08:01 PM, Yvan Roux wrote:
>> On 31 March 2016 at 20:54, Pedro Alves <address@hidden> wrote:
>>> On 03/31/2016 07:46 PM, Yvan Roux wrote:
>>>> 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
>>>
>>> I'm confused.  What about the other two processes?  Before
>>> you said none of the 4 processes is actually killed.  Was that
>>> incorrect?  If example.exe is in tracing stop, I'd expect
>>> gdb is still tracing it.
>>
>> Yes sorry, I only mentioned these 2 processes because they are only
>> one known by close_wait_program, and to which the various signals are
>> sent.
>>
>> So, none of the 4 processes are killed, sh and gdb are both in sleeping 
>> state.
>>
>
> Looking at your PIDs again:
>
> 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
>
> I looked around in guality's testsuite and I found it uses
> GDB's "run" command, not "attach", so I'd expect example.exe to be
> a child of GDB, but the PIDs above indicate it isn't.  How can this be?
>
> I didn't find the exact same gdb invocation like yours though,
> so maybe you have local changes that make it use "attach" for some
> reason?

No I'm using gcc trunk at revision 234447 (March 24th), I think you
didn't look at the same part of guality testing (if you looked at
lib/gcc-gdb-test.exp), I don't know well this part of the testsuite
but my understanding is that this test is self contained and attach
itself to gdb, this is all defined into gcc.dg/guality/guality.h (same
command line and attach command).