Re: PID-reuse races fix, introduced GCC validation brakage
Yvan Roux <[email protected]>
| Newsgroups | gmane.comp.sysutils.dejagnu.general |
|---|---|
| Message-ID | <CAD57uCduaSaWAUE+O7UZ9mgX6fSUD5dY4fmW2_iuij_Uv4EGkQ@mail.gmail.com> |
On 31 March 2016 at 21:27, Pedro Alves <[email protected]> wrote: > 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? 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).