GDB/testsuite: Extend the time gdbserver is waited for

  Hi,

 Gdbserver support code uses the global timeout value to determine when to 
stop waiting for a gdbserver process being started to respond before 
continuing anyway.  This timeout is usually as low as 10s and may not be 
enough in this context, for example on the first run where the filesystem 
cache is cold, even if it is elsewhere.

 E.g. I observe this reliably with gdbserver started the first time in 
QEMU running in the system emulation mode:

(gdb) file .../gdb.base/advance
Reading symbols from .../gdb.base/advance...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x87f8: file .../gdb.base/advance.c, 
line 41.
(gdb) set remotetimeout 15
(gdb) kill
The program is not being run.
(gdb)
[...]
.../bin/gdbserver --once :6014 advance
target remote localhost:6014
Remote debugging using localhost:6014
Remote communication error.  Target disconnected.: Connection reset by peer.
(gdb) continue
The program is not being run.
(gdb) Process advance created; pid = 999
Listening on port 6014
FAIL: gdb.base/advance.exp: Can't run to main

-- notice how the test harness proceeded with the `target remote ...' 
command even though gdbserver hasn't completed its startup yet.  A while 
later when it's finally ready it's too late already.  I checked the 
timing here and it takes gdbserver roughly 25 seconds to start in this 
scenario.  Subsequent gdbserver starts in the same test run take less time 
and usually complete within 10 seconds although occasionally `target 
remote ...' precedes the corresponding `Listening on port...' message 
again.

 Therefore I have fixed this problem by setting an explicit timeout to 
120s on the expect call in question.  If this turns out too arbitrary 
sometime, then perhaps a separate `gdbserver_timeout' setting might be 
due.

 Tested with arm-linux-gnueabi and mips-linux-gnu.  OK to apply?

2014-07-28  Maciej W. Rozycki  <macro@codesourcery.com>

	gdb/testsuite/
	* lib/gdbserver-support.exp (gdbserver_start): Set timeout to
	120 on waiting for the TCP socket to open.

  Maciej

gdb-test-gdbserver-start-timeout.diff
  

On 07/28/2014 08:34 PM, Maciej W. Rozycki wrote:

> gdb-test-gdbserver-start-timeout.diff
> Index: gdb-fsf-trunk-quilt/gdb/testsuite/lib/gdbserver-support.exp
> ===================================================================
> --- gdb-fsf-trunk-quilt.orig/gdb/testsuite/lib/gdbserver-support.exp	2014-05-13 02:52:11.347706187 +0100
> +++ gdb-fsf-trunk-quilt/gdb/testsuite/lib/gdbserver-support.exp	2014-05-30 01:45:51.658977074 +0100
> @@ -275,6 +275,7 @@ proc gdbserver_start { options arguments
>  	# Wait for the server to open its TCP socket, so that GDB can connect.
>  	expect {
>  	    -i $server_spawn_id
> +	    -timeout 120
>  	    -notransfer
>  	    -re "Listening on" { }
>  	    -re "Can't bind address: Address already in use\\.\r\n" {
> 

OK.

Wouldn't it be good to add a 'timeout {...}' case that emits a
warning or some such?

Thanks,
Pedro Alves
  

On Tue, 29 Jul 2014, Pedro Alves wrote:

> > gdb-test-gdbserver-start-timeout.diff
> > Index: gdb-fsf-trunk-quilt/gdb/testsuite/lib/gdbserver-support.exp
> > ===================================================================
> > --- gdb-fsf-trunk-quilt.orig/gdb/testsuite/lib/gdbserver-support.exp	2014-05-13 02:52:11.347706187 +0100
> > +++ gdb-fsf-trunk-quilt/gdb/testsuite/lib/gdbserver-support.exp	2014-05-30 01:45:51.658977074 +0100
> > @@ -275,6 +275,7 @@ proc gdbserver_start { options arguments
> >  	# Wait for the server to open its TCP socket, so that GDB can connect.
> >  	expect {
> >  	    -i $server_spawn_id
> > +	    -timeout 120
> >  	    -notransfer
> >  	    -re "Listening on" { }
> >  	    -re "Can't bind address: Address already in use\\.\r\n" {
> > 
> 
> OK.

 I have applied this change now, thanks for your review.

  Maciej