Increase timeout in gdb.mi/list-thread-groups-available.exp
Commit Message
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(-)
Comments
>>>>> "Simon" == Simon Marchi <simon.marchi@efficios.com> writes:
Simon> PR gdb/24863
Simon> * gdb.mi/list-thread-groups-available.exp: Increase timeout for
Simon> -list-thread-groups --available test.
Simon> +save_vars { timeout } {
Simon> + # Increase the timeout: when running with `make check-read1`, this can take
Simon> + # a bit of time, as there is a lot of output generated, hence a lot of read
Simon> + # syscalls.
Simon> + set timeout [expr $timeout * 10]
Maybe this should use with_timeout_factor.
Tom
On 8/1/19 3:38 PM, Simon Marchi wrote:
> 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.
A better approach to fix this is match a line at a time using gdb_test_multiple
and exp_continue.
-re "$process_entry_re" {
exp_continue
}
No need to bump the timeout that way, since by default exp_continue resets
the timeout timer.
Thanks,
Pedro Alves
@@ -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]