[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Pedro Alves
Subject: Re: PID-reuse races fix, introduced GCC validation brakage
Date: Thu, 31 Mar 2016 20:27:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1

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

Pedro Alves

reply via email to

[Prev in Thread] Current Thread [Next in Thread]