From: Simon Marchi <simon.marchi@efficios.com>
To: gdb-patches@sourceware.org
Cc: Tom de Vries <tdevries@suse.de>,
Simon Marchi <simon.marchi@efficios.com>
Subject: [PATCH] Increase timeout in gdb.mi/list-thread-groups-available.exp
Date: Thu, 01 Aug 2019 14:39:00 -0000 [thread overview]
Message-ID: <20190801143855.1640-1-simon.marchi@efficios.com> (raw)
Running
make check-read1 TESTS="gdb.mi/list-thread-groups-available.exp"
on my machine results in timeout failures. Running it while having
`tail -F testsuite/gdb.log` on the side shows that the test is never
really blocked, it is just slow at consuming the large output generated
by `-list-thread-groups --available` (which lists all the processes on
the system).
If I increase the timeout to a large value, the test passes in ~30
seconds (compared to under 1 second normally).
Increase the timeout for the particular mi_gdb_test that is long to
execute under read1. The new timeout value is a bit arbitrary. The
default timeout is 10 seconds, so I set the new timeout to be
"old-timeout * 10", so 100 seconds in the typical case.
gdb/testsuite/ChangeLog:
PR gdb/24863
* gdb.mi/list-thread-groups-available.exp: Increase timeout for
-list-thread-groups --available test.
---
.../gdb.mi/list-thread-groups-available.exp | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/gdb/testsuite/gdb.mi/list-thread-groups-available.exp b/gdb/testsuite/gdb.mi/list-thread-groups-available.exp
index 792c3bac8962..c8486ce1f3d1 100644
--- a/gdb/testsuite/gdb.mi/list-thread-groups-available.exp
+++ b/gdb/testsuite/gdb.mi/list-thread-groups-available.exp
@@ -54,10 +54,18 @@ set cores_re "cores=\\\[(\"$decimal\"(,\"$decimal\")*)?\\\]"
# List all available processes.
set process_entry_re "{${id_re},${type_re}(,$description_re)?(,$user_re)?(,$cores_re)?}"
-mi_gdb_test \
- "-list-thread-groups --available" \
- "\\^done,groups=\\\[${process_entry_re}(,$process_entry_re)*\\\]" \
- "list available thread groups"
+save_vars { timeout } {
+ # Increase the timeout: when running with `make check-read1`, this can take
+ # a bit of time, as there is a lot of output generated, hence a lot of read
+ # syscalls.
+ set timeout [expr $timeout * 10]
+
+ mi_gdb_test \
+ "-list-thread-groups --available" \
+ "\\^done,groups=\\\[${process_entry_re}(,$process_entry_re)*\\\]" \
+ "list available thread groups"
+}
+
# List specific processes, make sure there are two entries.
set spawn_id_1 [remote_spawn target $binfile]
--
2.22.0
next reply other threads:[~2019-08-01 14:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-01 14:39 Simon Marchi [this message]
2019-08-01 18:18 ` Tom Tromey
2019-08-01 19:16 ` Simon Marchi
[not found] ` <cba4616c-4e3c-4217-7c7a-40fb576ea351@suse.de>
2019-08-02 13:43 ` Tom Tromey
2019-08-02 14:46 ` Simon Marchi
2019-08-05 13:58 ` Tom de Vries
2019-08-05 14:23 ` Simon Marchi
2019-08-05 13:53 ` Tom de Vries
2019-08-15 17:58 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190801143855.1640-1-simon.marchi@efficios.com \
--to=simon.marchi@efficios.com \
--cc=gdb-patches@sourceware.org \
--cc=tdevries@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox