| Message ID | 20190801143855.1640-1-simon.marchi@efficios.com |
|---|---|
| State | New |
| Headers | show |
>>>>> "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
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]
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(-)