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 _______________________________________________ DejaGnu mailing list DejaGnu@gnu.org https://lists.gnu.org/mailman/listinfo/dejagnu
