Re: [PATCH] improve python finish breakpoint for exceptions/longjmp case.

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Wed, 24 Oct 2012 22:48:15 +0200, Andrew Burgess wrote:
> On 17/10/2012 5:27 PM, Jan Kratochvil wrote:
> > Also testcases should not remain hanging indefinitely if something breaks, in
> > this case 'alarm (60);' at the start of 'main' should ensure that I think.
> 
> I'm confused why this test would need to take care of shutting itself down,
> if the test failed would dejagnu not timeout the test, and eventually gdb
> would exit taking down the inferior as it does?

For exampe if GDB crashes the inferior process is left running.


> I had a look for other tests that used alarm() but there are only a few and I
> didn't think any of these were trying to perform a defensive shutdown as you're
> suggesting, so can you point at any other test that needs to do this sort of
> thing, or is there something special about this test?

This is a general problem of the GDB testsuite, this is why Fedora uses
	http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-orphanripper.c
wrapper for running the testsuite to kill any leftover running processes.

Otherwise if you do some 'make check &>file' it will hang forever as a single
leftover process will still have its STDOUT/STDERR open blocking the finish.

If the whole GDB testsuite was written properly this 'orphanripper' wrapper
was not needed.  Currently FSF GDB does not carry this 'orphanripper' wrapper,
for FSF GDB there are possibilities:
 (1) FSF GDB could adopt this 'orphanripper' wrapper.  It is not the right
     solution but it works.
 (2) Someone could review all the testsuite/*/*.c (and even *.exp) files and
     protect them properly.  This is easy work so it should be doable despite
     the number of files.
 (3) We could switch to non-dejagnu testsuite capable of tracking spawned
     processes on its own (even if GDB crashes).  But I am not aware of any
     such testsuite framework so it would be a custom tool which is equivalent
     to (1).


Thanks,
Jan