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

[Pedro Alves]

On 03/31/2016 08:48 PM, Yvan Roux wrote:

> 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).

Ah, makes sense now.  It's example.exe that spawns gdb, and has gdb
attach to its parent, which is example.exe.  That's why runtest only
knows about example.exe (pid 100), and cat (pid 101).  These were
the processes that runtest started with "open |".

And I think that explains why cat is zombie and example.exe is
in "tracing stop".  It must be that cat dies from the SIGINT, but gdb intercepts
example.exe's SIGINT with the usual "Program received signal SIGINT, Interrupt."
indication, so example.exe gets stuck in "ptrace stop" forever
"deadlocked" with gdb, since gdb never continues from the SIGINT.

I think that it should be possible to run example.exe manually,
with some infinite loop hacked in, type ctrl-c, and observe that
it doesn't exit gracefully.

So, from an "exit-gracefully" perspective, what about having guality.h do
"handle SIGINT pass nostop" before the "attach" command, so that SIGINT
reaches the example.exe process, which should then exit and bring
down gdb with it?  Same for SIGTERM.

That still doesn't explain why did "wait" return "0", and why did
it return at all.  I thought that maybe it returned because cat
did exit and then that wait reaped cat.  Like, maybe you need to call
wait once for each process behind the spawn id?  I couldn't find
documentation about how wait should work with a pipeline, but if cat
is still zombie, that doesn't sound like it.

We'd need that wait working in order to force-kill the pipeline if
things go south.  Though, gdb doesn't ever crash, right?  ;-)

Thanks,
Pedro Alves