Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [PATCH] gdb/testsuite: use with_timeout_factor in 2 more tests
@ 2026-10-05  9:52 Jan Vrany
  2026-10-05 14:03 ` Simon Marchi
  0 siblings, 1 reply; 3+ messages in thread
From: Jan Vrany @ 2026-10-05  9:52 UTC (permalink / raw)
  To: gdb-patches; +Cc: Jan Vrany

When running tests on some really slow targets, I got timeout in
gdb.base/funcargs.exp and gdb.base/completion.exp. The usual remedy I
use is to set timeout to higher value in site.exp.

However this does not help in case of aforementioned tests because they
set timeout to fixed value, regardless of whether the timeout has been
increased or not, causing them to fail on some of my machines.

This commit fixes the problem by using with_timeout_factor.

Since with_timeout_factor wraps large chunks of code, I decided not
to reformat (indent) it to make the patch easier to read and to
avoid "noise" when git-blaming.
---
 gdb/testsuite/gdb.base/completion.exp |  6 +++++-
 gdb/testsuite/gdb.base/funcargs.exp   | 11 +++++++----
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/gdb/testsuite/gdb.base/completion.exp b/gdb/testsuite/gdb.base/completion.exp
index 44cf649d5b6..f145f084999 100644
--- a/gdb/testsuite/gdb.base/completion.exp
+++ b/gdb/testsuite/gdb.base/completion.exp
@@ -61,7 +61,8 @@ if {![runto_main]} {
     return
 }
 
-set timeout 30
+with_timeout_factor 3 {
+
 gdb_test_no_output "set max-completions unlimited"
 
 gdb_test_no_output "complete print values\[0\].x." \
@@ -995,3 +996,6 @@ foreach_with_prefix spc { " " "" } {
 	    }
     }
 }
+
+# end of with_timeout_factor
+}
diff --git a/gdb/testsuite/gdb.base/funcargs.exp b/gdb/testsuite/gdb.base/funcargs.exp
index fdfdf07b78c..dd3240ba5e0 100644
--- a/gdb/testsuite/gdb.base/funcargs.exp
+++ b/gdb/testsuite/gdb.base/funcargs.exp
@@ -1031,13 +1031,15 @@ proc_with_prefix stepping_over_trampolines { } {
     }
 }
 
-set prev_timeout $timeout
+
 if {[istarget "mips*tx39-*"]} {
-    set timeout 300
+    set timeout_factor 30
 } else {
-    set timeout 60
+    set timeout_factor 6
 }
 
+with_timeout_factor $timeout_factor {
+
 # Determine expected output for unsigned long variables,
 # the output varies with sizeof (unsigned long).
 
@@ -1104,4 +1106,5 @@ call_after_alloca
 localvars_in_indirect_call
 stepping_over_trampolines
 
-set timeout $prev_timeout
+# end of with_timeout_factor
+}
-- 
2.53.0



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

* Re: [PATCH] gdb/testsuite: use with_timeout_factor in 2 more tests
  2026-10-05  9:52 [PATCH] gdb/testsuite: use with_timeout_factor in 2 more tests Jan Vrany
@ 2026-10-05 14:03 ` Simon Marchi
  2026-10-06 10:28   ` Jan Vrany
  0 siblings, 1 reply; 3+ messages in thread
From: Simon Marchi @ 2026-10-05 14:03 UTC (permalink / raw)
  To: Jan Vrany, gdb-patches

On 10/5/26 5:52 AM, Jan Vrany wrote:
> When running tests on some really slow targets, I got timeout in
> gdb.base/funcargs.exp and gdb.base/completion.exp. The usual remedy I
> use is to set timeout to higher value in site.exp.

I'd be curious to know which tests in those files exactly, see if we can
improve either the test or GDB.

> However this does not help in case of aforementioned tests because they
> set timeout to fixed value, regardless of whether the timeout has been
> increased or not, causing them to fail on some of my machines.
> 
> This commit fixes the problem by using with_timeout_factor.
> 
> Since with_timeout_factor wraps large chunks of code, I decided not
> to reformat (indent) it to make the patch easier to read and to
> avoid "noise" when git-blaming.

I would suggest do the re-indent.  I find readability of current code
more important than hypothetic git-blamability.  Plus, I believe that
anyone doing any serious git-blaming should use a better tool than plain
bit-blame, allowing to easily jump over uninteresting commits (for
instance, I use "tig blame" and jumping over an uninteresting commit is
one keystroke).

> ---
>  gdb/testsuite/gdb.base/completion.exp |  6 +++++-
>  gdb/testsuite/gdb.base/funcargs.exp   | 11 +++++++----
>  2 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.base/completion.exp b/gdb/testsuite/gdb.base/completion.exp
> index 44cf649d5b6..f145f084999 100644
> --- a/gdb/testsuite/gdb.base/completion.exp
> +++ b/gdb/testsuite/gdb.base/completion.exp
> @@ -61,7 +61,8 @@ if {![runto_main]} {
>      return
>  }
>  
> -set timeout 30
> +with_timeout_factor 3 {
> +
>  gdb_test_no_output "set max-completions unlimited"
>  
>  gdb_test_no_output "complete print values\[0\].x." \
> @@ -995,3 +996,6 @@ foreach_with_prefix spc { " " "" } {
>  	    }
>      }
>  }
> +
> +# end of with_timeout_factor
> +}
> diff --git a/gdb/testsuite/gdb.base/funcargs.exp b/gdb/testsuite/gdb.base/funcargs.exp
> index fdfdf07b78c..dd3240ba5e0 100644
> --- a/gdb/testsuite/gdb.base/funcargs.exp
> +++ b/gdb/testsuite/gdb.base/funcargs.exp
> @@ -1031,13 +1031,15 @@ proc_with_prefix stepping_over_trampolines { } {
>      }
>  }
>  
> -set prev_timeout $timeout
> +
>  if {[istarget "mips*tx39-*"]} {
> -    set timeout 300
> +    set timeout_factor 30
>  } else {
> -    set timeout 60
> +    set timeout_factor 6
>  }

I would suggest getting rid of this special "mips*tx39-*" case.

LGTM with those fixed.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Simon

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

* Re: [PATCH] gdb/testsuite: use with_timeout_factor in 2 more tests
  2026-10-05 14:03 ` Simon Marchi
@ 2026-10-06 10:28   ` Jan Vrany
  0 siblings, 0 replies; 3+ messages in thread
From: Jan Vrany @ 2026-10-06 10:28 UTC (permalink / raw)
  To: Simon Marchi, gdb-patches

On Mon, 2026-10-05 at 10:03 -0400, Simon Marchi wrote:
> On 10/5/26 5:52 AM, Jan Vrany wrote:
> > When running tests on some really slow targets, I got timeout in
> > gdb.base/funcargs.exp and gdb.base/completion.exp. The usual remedy I
> > use is to set timeout to higher value in site.exp.
> 
> I'd be curious to know which tests in those files exactly, see if we can
> improve either the test or GDB.

On my Vision5 RISC-V board I saw completion tests failing:

Running /home/jv/Projects/gdb/master/build/riscv64-linux-gnu/gdb/testsuite/../../../../gdb/testsuite/gdb.base/completion.exp ...
FAIL: gdb.base/completion.exp: complete 'p ' (timeout)
FAIL: gdb.base/completion.exp: complete 'info t foo' (timeout)
FAIL: gdb.base/completion.exp: complete 'info t' (timeout)
FAIL: gdb.base/completion.exp: complete 'info t ' (timeout)
FAIL: gdb.base/completion.exp: complete 'info asdfgh' (timeout)
FAIL: gdb.base/completion.exp: complete 'info asdfgh ' (timeout)
FAIL: gdb.base/completion.exp: complete 'info' (timeout)
FAIL: gdb.base/completion.exp: complete 'info ' (timeout)
FAIL: gdb.base/completion.exp: complete (2) 'info ' (timeout)
FAIL: gdb.base/completion.exp: complete 'help info wat' (timeout)
FAIL: gdb.base/completion.exp: complete 'p "break1' (timeout)
FAIL: gdb.base/completion.exp: complete 'p 'arg' (timeout)
FAIL: gdb.base/completion.exp: complete (2) 'p 'arg' (timeout)
FAIL: gdb.base/completion.exp: complete 'handle signal' (timeout)
FAIL: gdb.base/completion.exp: complete 'handle keyword' (timeout)
FAIL: gdb.base/completion.exp: complete help aliases (timeout)
FAIL: gdb.base/completion.exp: complete 'p no_var_named_this-arg' (timeout)
FAIL: gdb.base/completion.exp: complete (2) 'p no_var_named_this-arg' (timeout)
FAIL: gdb.base/completion.exp: complete (2) 'p no_var_named_this-' (timeout)
FAIL: gdb.base/completion.exp: complete 'p values[0].a' (timeout)
FAIL: gdb.base/completion.exp: complete 'p values[0] . a' (timeout)
FAIL: gdb.base/completion.exp: complete 'p &values[0] -> a' (timeout)
FAIL: gdb.base/completion.exp: completion of field in anonymous union

It think it is really just the CPU being slow by today's standards.

Interestingly, I cannot reproduce gdb.base/funcargs.exp failures on any
of my machines though I'm pretty sure I've seen them. Perhaps they were
overloaded or some NFS issue. Anyways, I think it would be better to
use with_timeout_factor there too just in case.

> 
> > However this does not help in case of aforementioned tests because they
> > set timeout to fixed value, regardless of whether the timeout has been
> > increased or not, causing them to fail on some of my machines.
> > 
> > This commit fixes the problem by using with_timeout_factor.
> > 
> > Since with_timeout_factor wraps large chunks of code, I decided not
> > to reformat (indent) it to make the patch easier to read and to
> > avoid "noise" when git-blaming.
> 
> I would suggest do the re-indent.  I find readability of current code
> more important than hypothetic git-blamability.  Plus, I believe that
> anyone doing any serious git-blaming should use a better tool than plain
> bit-blame, allowing to easily jump over uninteresting commits (for
> instance, I use "tig blame" and jumping over an uninteresting commit is
> one keystroke).

Fair point - will reformat.

Thanks!
> 
> > ---
> >  gdb/testsuite/gdb.base/completion.exp |  6 +++++-
> >  gdb/testsuite/gdb.base/funcargs.exp   | 11 +++++++----
> >  2 files changed, 12 insertions(+), 5 deletions(-)
> > 
> > diff --git a/gdb/testsuite/gdb.base/completion.exp b/gdb/testsuite/gdb.base/completion.exp
> > index 44cf649d5b6..f145f084999 100644
> > --- a/gdb/testsuite/gdb.base/completion.exp
> > +++ b/gdb/testsuite/gdb.base/completion.exp
> > @@ -61,7 +61,8 @@ if {![runto_main]} {
> >      return
> >  }
> > 
> > -set timeout 30
> > +with_timeout_factor 3 {
> > +
> >  gdb_test_no_output "set max-completions unlimited"
> > 
> >  gdb_test_no_output "complete print values\[0\].x." \
> > @@ -995,3 +996,6 @@ foreach_with_prefix spc { " " "" } {
> >  	    }
> >      }
> >  }
> > +
> > +# end of with_timeout_factor
> > +}
> > diff --git a/gdb/testsuite/gdb.base/funcargs.exp b/gdb/testsuite/gdb.base/funcargs.exp
> > index fdfdf07b78c..dd3240ba5e0 100644
> > --- a/gdb/testsuite/gdb.base/funcargs.exp
> > +++ b/gdb/testsuite/gdb.base/funcargs.exp
> > @@ -1031,13 +1031,15 @@ proc_with_prefix stepping_over_trampolines { } {
> >      }
> >  }
> > 
> > -set prev_timeout $timeout
> > +
> >  if {[istarget "mips*tx39-*"]} {
> > -    set timeout 300
> > +    set timeout_factor 30
> >  } else {
> > -    set timeout 60
> > +    set timeout_factor 6
> >  }
> 
> I would suggest getting rid of this special "mips*tx39-*" case.
> 
> LGTM with those fixed.
> 
> Approved-By: Simon Marchi <simon.marchi@efficios.com>
> 
> Simon


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

end of thread, other threads:[~2026-10-06 10:29 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-05  9:52 [PATCH] gdb/testsuite: use with_timeout_factor in 2 more tests Jan Vrany
2026-10-05 14:03 ` Simon Marchi
2026-10-06 10:28   ` Jan Vrany

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox