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

Pedro Alves <[email protected]>
Newsgroups gmane.comp.sysutils.dejagnu.general
Message-ID <[email protected]>
On 03/31/2016 08:01 PM, Yvan Roux wrote:
> On 31 March 2016 at 20:54, Pedro Alves <[email protected]> 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?

Thanks,
Pedro Alves
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.