diff mbox

Increase timeout in gdb.mi/list-thread-groups-available.exp

Message ID 20190801143855.1640-1-simon.marchi@efficios.com
State New
Headers show

Commit Message

Simon Marchi Aug. 1, 2019, 2:38 p.m. UTC
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

Tom Tromey Aug. 1, 2019, 6:18 p.m. UTC | #1
>>>>> "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
Pedro Alves Aug. 15, 2019, 5:58 p.m. UTC | #2
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 mbox

Patch

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]