[gdb/testsuite] Fix timeout in gdb.base/valgrind-infcall-2.exp

Message ID 9910b2a3-4b77-ad95-686c-9bd3a7e7f6ca@suse.de
State New
Headers show
Series
  • [gdb/testsuite] Fix timeout in gdb.base/valgrind-infcall-2.exp
Related show

Commit Message

Tom de Vries April 29, 2021, 1:57 p.m.
[ was: Re: [PATCH] GDB: Fix test case gdb.base/valgrind-bt.exp. ]

On 4/29/21 1:46 PM, Tom de Vries wrote:
> On 4/29/21 1:28 PM, Tom de Vries wrote:

>> On 4/19/21 11:22 PM, Carl Love via Gdb-patches wrote:

>>> diff --git a/gdb/testsuite/lib/valgrind.exp b/gdb/testsuite/lib/valgrind.exp

>>> index c214491f7b8..caabeda9730 100644

>>> --- a/gdb/testsuite/lib/valgrind.exp

>>> +++ b/gdb/testsuite/lib/valgrind.exp

>>> @@ -82,12 +82,15 @@ proc vgdb_start { {active_at_startup 1} } {

>>>  

>>>      clean_restart $testfile

>>>  

>>> +    set vgdbcmd "set remotetimeout 3"

>>> +

>>>      # Make sure we're disconnected, in case we're testing with the

>>>      # native-extended-gdbserver board, where gdb_start/gdb_load spawn

>>>      # gdbserver and connect to it.

>>>      gdb_test "disconnect" ".*"

>>>  

>>> -    set vgdbcmd "target remote | vgdb --wait=1 --pid=$vgdbpid"

>>> +    set vgdbcmd "target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=$vgdbpid"

>>> +

>>>      if { $active_at_startup } {

>>>  	gdb_test "$vgdbcmd" " in \\.?_start .*" "target remote for vgdb"

>>>      } else {

>>>

>>

>> AFAICT, the first "set vgdbcmd" doesn't achieve anything.

>>

>> The value is overwritten by the second "set vgdbcmd".

> 

> This actually sets the remotetimeout, and increasing the value to 4

> fixes the FAIL I reported:


Patch below fixes the FAIL.

Any comments?

Thanks,
- Tom

Comments

Frank Ch. Eigler via Gdb-patches April 29, 2021, 3:45 p.m. | #1
On 4/29/21 6:57 AM, Tom de Vries wrote:
> [ was: Re: [PATCH] GDB: Fix test case gdb.base/valgrind-bt.exp. ]

> 

> On 4/29/21 1:46 PM, Tom de Vries wrote:

>> On 4/29/21 1:28 PM, Tom de Vries wrote:

>>> On 4/19/21 11:22 PM, Carl Love via Gdb-patches wrote:

>>>> diff --git a/gdb/testsuite/lib/valgrind.exp b/gdb/testsuite/lib/valgrind.exp

>>>> index c214491f7b8..caabeda9730 100644

>>>> --- a/gdb/testsuite/lib/valgrind.exp

>>>> +++ b/gdb/testsuite/lib/valgrind.exp

>>>> @@ -82,12 +82,15 @@ proc vgdb_start { {active_at_startup 1} } {

>>>>  

>>>>      clean_restart $testfile

>>>>  

>>>> +    set vgdbcmd "set remotetimeout 3"

>>>> +

>>>>      # Make sure we're disconnected, in case we're testing with the

>>>>      # native-extended-gdbserver board, where gdb_start/gdb_load spawn

>>>>      # gdbserver and connect to it.

>>>>      gdb_test "disconnect" ".*"

>>>>  

>>>> -    set vgdbcmd "target remote | vgdb --wait=1 --pid=$vgdbpid"

>>>> +    set vgdbcmd "target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=$vgdbpid"

>>>> +

>>>>      if { $active_at_startup } {

>>>>  	gdb_test "$vgdbcmd" " in \\.?_start .*" "target remote for vgdb"

>>>>      } else {

>>>>

>>>

>>> AFAICT, the first "set vgdbcmd" doesn't achieve anything.

>>>

>>> The value is overwritten by the second "set vgdbcmd".

>>

>> This actually sets the remotetimeout, and increasing the value to 4

>> fixes the FAIL I reported:


Well done! I completely overlooked that. :-(

> 

> Patch below fixes the FAIL.

> 

> Any comments?


AFAICT, that looks like the correct way to do this.

Thank you for fixing this.

Keith
Frank Ch. Eigler via Gdb-patches April 30, 2021, 8:13 a.m. | #2
On Thu, Apr 29, 2021 at 03:57:41PM +0200, Tom de Vries wrote:

> Patch below fixes the FAIL.

> 

> Any comments?


I agree, this patch is OK.   Sorry for overlooking the problem,
and thanks for providing a fix!

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

Patch

[gdb/testsuite] Fix timeout in gdb.base/valgrind-infcall-2.exp

Since commit 6d5702a5eb3 "Fix test case gdb.base/valgrind-bt.exp" I run into:
...
FAIL: gdb.base/valgrind-infcall-2.exp: target remote for vgdb (timeout)
FAIL: gdb.base/valgrind-infcall-2.exp: monitor v.set gdb_output (timeout)
...

The commit adds this line in proc vgdb_start:
...
    set vgdbcmd "set remotetimeout 3"
...
which has no effect given that the value of var vgdbcmd is not used before
it's overwritten.  We can fix this by doing instead:
...
    set_remotetimeout 3
...

The FAIL I'm observing is fixed by increasing the remotetimeout value to 4.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-04-29  Tom de Vries  <tdevries@suse.de>

	PR testsuite/27786
	* lib/valgrind.exp (vgdb_start): Use set_remotetimeout.  Increase
	remotetimeout to 4.

---
 gdb/testsuite/lib/valgrind.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/testsuite/lib/valgrind.exp b/gdb/testsuite/lib/valgrind.exp
index caabeda9730..bba338f880c 100644
--- a/gdb/testsuite/lib/valgrind.exp
+++ b/gdb/testsuite/lib/valgrind.exp
@@ -82,7 +82,7 @@  proc vgdb_start { {active_at_startup 1} } {
 
     clean_restart $testfile
 
-    set vgdbcmd "set remotetimeout 3"
+    set_remotetimeout 4
 
     # Make sure we're disconnected, in case we're testing with the
     # native-extended-gdbserver board, where gdb_start/gdb_load spawn