This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[PATCH] GDB/testsuite: Extend the time gdbserver is waited for
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: <gdb-patches at sourceware dot org>
- Date: Mon, 28 Jul 2014 20:34:33 +0100
- Subject: [PATCH] GDB/testsuite: Extend the time gdbserver is waited for
- Authentication-results: sourceware.org; auth=none
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
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" {