diff mbox series

gdb/testsuite: Increase timeout when using read1 in gdb.base/osabi.exp

Message ID 20240301192750.1208030-1-thiago.bauermann@linaro.org
State New
Headers
Series gdb/testsuite: Increase timeout when using read1 in gdb.base/osabi.exp |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gdb_build--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 success Testing passed
linaro-tcwg-bot/tcwg_gdb_check--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 success Testing passed

Commit Message

Thiago Jung Bauermann March 1, 2024, 7:27 p.m. UTC 
  The Linaro CI runs the GDB testsuite using the read1 tool, which
significantly increases the time it takes DejaGNU to read inferior output.
On top of that, sometimes the test machine has higher than normal load,
which causes tests to run even slower.

Because the gdb.base/osabi.exp enables "debug arch" output, which is
somewhat verbose, it sometimes fails when running in the Linaro CI
environment.

Fix this problem by using a timeout factor to run the test.
---
 gdb/testsuite/gdb.base/osabi.exp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Comments

Simon Marchi March 1, 2024, 8:36 p.m. UTC | #1 
On 3/1/24 14:27, Thiago Jung Bauermann wrote:
> The Linaro CI runs the GDB testsuite using the read1 tool, which
> significantly increases the time it takes DejaGNU to read inferior output.
> On top of that, sometimes the test machine has higher than normal load,
> which causes tests to run even slower.
> 
> Because the gdb.base/osabi.exp enables "debug arch" output, which is
> somewhat verbose, it sometimes fails when running in the Linaro CI
> environment.
> 
> Fix this problem by using a timeout factor to run the test.
> ---
>  gdb/testsuite/gdb.base/osabi.exp | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.base/osabi.exp b/gdb/testsuite/gdb.base/osabi.exp
> index 9bbfff52bae8..47d5755f1584 100644
> --- a/gdb/testsuite/gdb.base/osabi.exp
> +++ b/gdb/testsuite/gdb.base/osabi.exp
> @@ -27,4 +27,6 @@ proc test_set_osabi_none { } {
>      gdb_test "set osabi none" ".*gdbarch_find_by_info: info.osabi 1 \\(none\\).*"
>  }
>  
> -test_set_osabi_none
> +with_read1_timeout_factor 10 {
> +    test_set_osabi_none
> +}

Hi Thiago,

If it was really a case of "GDB is thinking for a long time before
spewing out an answer", then I think that increasing the timeout would
be the right fix (or, make GDB faster).

But here, it appears that it's GDB outputting a lot of lines, and
dejagnu taking some time to read it.  I'm actually surprised that
dejagnu times out, since it's constantly reading characters (one at a
time), I would think that it would constantly reset its timeout timer.
But perhaps the timeout applies to the whole gdb_test command.  I don't
recall, I haven't touched that in a while.

Anyhow, a common way to fix this without bumping the timeout is to
change the test to use a line by line approach.  Typically by using
gdb_test_multiple to consume one line at a time and to keep reading
until the prompt is seen.  The test can set a flag to indicate whether
the searched-for string has been seen, and do a gdb_assert at the end.
There might be some smarter ways to do this today, I'm not super
up-to-date with the latest testsuite improvements.

Simon
Thiago Jung Bauermann March 1, 2024, 8:54 p.m. UTC | #2 
Hello Simon,

Simon Marchi <simark@simark.ca> writes:

> If it was really a case of "GDB is thinking for a long time before
> spewing out an answer", then I think that increasing the timeout would
> be the right fix (or, make GDB faster).
>
> But here, it appears that it's GDB outputting a lot of lines, and
> dejagnu taking some time to read it.  I'm actually surprised that
> dejagnu times out, since it's constantly reading characters (one at a
> time), I would think that it would constantly reset its timeout timer.
> But perhaps the timeout applies to the whole gdb_test command.  I don't
> recall, I haven't touched that in a while.
>
> Anyhow, a common way to fix this without bumping the timeout is to
> change the test to use a line by line approach.  Typically by using
> gdb_test_multiple to consume one line at a time and to keep reading
> until the prompt is seen.  The test can set a flag to indicate whether
> the searched-for string has been seen, and do a gdb_assert at the end.
> There might be some smarter ways to do this today, I'm not super
> up-to-date with the latest testsuite improvements.

Makes sense, I'll post a v2 that uses that approach. Thank you for the
quick feedback!
diff mbox series

Patch

diff --git a/gdb/testsuite/gdb.base/osabi.exp b/gdb/testsuite/gdb.base/osabi.exp
index 9bbfff52bae8..47d5755f1584 100644
--- a/gdb/testsuite/gdb.base/osabi.exp
+++ b/gdb/testsuite/gdb.base/osabi.exp
@@ -27,4 +27,6 @@  proc test_set_osabi_none { } {
     gdb_test "set osabi none" ".*gdbarch_find_by_info: info.osabi 1 \\(none\\).*"
 }
 
-test_set_osabi_none
+with_read1_timeout_factor 10 {
+    test_set_osabi_none
+}