public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] gdb/testsuite: Increase timeout when using read1 in gdb.base/osabi.exp
@ 2024-03-01 19:27 Thiago Jung Bauermann
  2024-03-01 20:36 ` Simon Marchi
  0 siblings, 1 reply; 3+ messages in thread
From: Thiago Jung Bauermann @ 2024-03-01 19:27 UTC (permalink / raw)
  To: gdb-patches

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
+}

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] gdb/testsuite: Increase timeout when using read1 in gdb.base/osabi.exp
  2024-03-01 19:27 [PATCH] gdb/testsuite: Increase timeout when using read1 in gdb.base/osabi.exp Thiago Jung Bauermann
@ 2024-03-01 20:36 ` Simon Marchi
  2024-03-01 20:54   ` Thiago Jung Bauermann
  0 siblings, 1 reply; 3+ messages in thread
From: Simon Marchi @ 2024-03-01 20:36 UTC (permalink / raw)
  To: Thiago Jung Bauermann, gdb-patches

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] gdb/testsuite: Increase timeout when using read1 in gdb.base/osabi.exp
  2024-03-01 20:36 ` Simon Marchi
@ 2024-03-01 20:54   ` Thiago Jung Bauermann
  0 siblings, 0 replies; 3+ messages in thread
From: Thiago Jung Bauermann @ 2024-03-01 20:54 UTC (permalink / raw)
  To: Simon Marchi; +Cc: gdb-patches


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!

-- 
Thiago

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-03-01 20:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-01 19:27 [PATCH] gdb/testsuite: Increase timeout when using read1 in gdb.base/osabi.exp Thiago Jung Bauermann
2024-03-01 20:36 ` Simon Marchi
2024-03-01 20:54   ` Thiago Jung Bauermann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).