public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Thiago Jung Bauermann <thiago.bauermann@linaro.org>,
	gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb/testsuite: Increase timeout when using read1 in gdb.base/osabi.exp
Date: Fri, 1 Mar 2024 15:36:32 -0500	[thread overview]
Message-ID: <afe0e751-7c37-4829-b8d6-649c0085e1c1@simark.ca> (raw)
In-Reply-To: <20240301192750.1208030-1-thiago.bauermann@linaro.org>

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

  reply	other threads:[~2024-03-01 20:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-01 19:27 Thiago Jung Bauermann
2024-03-01 20:36 ` Simon Marchi [this message]
2024-03-01 20:54   ` Thiago Jung Bauermann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=afe0e751-7c37-4829-b8d6-649c0085e1c1@simark.ca \
    --to=simark@simark.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=thiago.bauermann@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).