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

[Yvan Roux]

Hi Pedro,

On 1 April 2016 at 00:07, Pedro Alves <address@hidden> wrote:

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

Yes that's it.

> 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 made some experiments outside dejagnu context, and the issue is due
to gdb receives a SIGSEGV from the test, and as SIGSEGV is handled
with stop = yes it creates the deadlock.

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

Yes, I agree that guality.h should be changed, but for handling
SIGSEGV and maybe all the signals marked as stop, at least for the
testcases which don't want to test signals.

Adding "handle SIGSEGV pass nostop print" works on that example, I'll
do a full validation and submit it upstream.

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

Yes, that's still fuzzy for me, I tried with removing the kill -2 to
avoid cat zombification, and it doesn't work better.  Yes, It looks
like wait has to be called for each processes.

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

:)

Cheers,
Yvan