* [PATCH][gdb/testsuite] Give up after consecutive timeouts in completion-support.exp
@ 2020-03-16 17:59 Tom de Vries
2020-03-17 8:06 ` Tom de Vries
2020-03-17 14:30 ` Simon Marchi
0 siblings, 2 replies; 6+ messages in thread
From: Tom de Vries @ 2020-03-16 17:59 UTC (permalink / raw)
To: gdb-patches
Hi,
When running test-case gdb.linespec/cpcompletion.exp with target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, we run into lots of
timeouts, in particular with this pattern:
...
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
cmd complete "b template2_"
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
tab complete "b template2_st" (timeout)
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
cmd complete "b template2_st"
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
tab complete "b template2_str" (timeout)
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
cmd complete "b template2_str"
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
tab complete "b template2_stru" (timeout)
...
Fix this by detecting timeouts in test_complete_prefix_range_re and giving up
after 3 consecutive timeouts.
This reduces testing time from ~39m to ~9m.
Tested on x86_64-linux.
OK for trunk?
Thanks,
- Tom
[gdb/testsuite] Give up after consecutive timeouts in completion-support.exp
---
gdb/testsuite/lib/completion-support.exp | 27 +++++++++++++++++++++++++--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/gdb/testsuite/lib/completion-support.exp b/gdb/testsuite/lib/completion-support.exp
index 03959e4c7f..18eac827f5 100644
--- a/gdb/testsuite/lib/completion-support.exp
+++ b/gdb/testsuite/lib/completion-support.exp
@@ -108,13 +108,19 @@ proc test_gdb_complete_tab_unique { input_line complete_line_re append_char_re }
set test "tab complete \"$input_line\""
send_gdb "$input_line\t"
+ set res 1
gdb_test_multiple "" "$test" {
-re "^$complete_line_re$append_char_re$" {
pass "$test"
}
+ timeout {
+ fail "$test (timeout)"
+ set res -1
+ }
}
clear_input_line $test
+ return $res
}
# Test that completing INPUT_LINE with TAB completes to "INPUT_LINE +
@@ -242,7 +248,10 @@ proc test_gdb_complete_none { input_line } {
proc test_gdb_complete_unique_re { input_line complete_line_re {append_char " "} {max_completions 0}} {
set append_char_re [string_to_regexp $append_char]
if { [readline_is_used] } {
- test_gdb_complete_tab_unique $input_line $complete_line_re $append_char_re
+ if { [test_gdb_complete_tab_unique $input_line $complete_line_re \
+ $append_char_re] == -1 } {
+ return -1
+ }
}
# Trim INPUT_LINE and COMPLETE LINE, for the case we're completing
@@ -266,6 +275,7 @@ proc test_gdb_complete_unique_re { input_line complete_line_re {append_char " "}
}
test_gdb_complete_cmd_unique $input_line $expected_output_re
+ return 1
}
# Like TEST_GDB_COMPLETE_UNIQUE_RE, but COMPLETE_LINE is a string, not
@@ -301,9 +311,22 @@ proc test_complete_prefix_range_re {input completion_re start {end -1}} {
set end [string length $input]
}
+ set timeouts 0
+ set max_timeouts 3
for {set i $start} {$i < $end} {incr i} {
set line [string range $input 0 $i]
- test_gdb_complete_unique_re "$line" $completion_re
+ set res [test_gdb_complete_unique_re "$line" $completion_re]
+ if { $res == -1 } {
+ incr timeouts
+ } else {
+ if { $timeouts > 0 } {
+ set timeouts 0
+ }
+ }
+ if { $timeouts == $max_timeouts } {
+ verbose -log "Consecutive timeouts in test_complete_prefix_range_re, giving up"
+ break
+ }
}
}
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH][gdb/testsuite] Give up after consecutive timeouts in completion-support.exp
2020-03-16 17:59 [PATCH][gdb/testsuite] Give up after consecutive timeouts in completion-support.exp Tom de Vries
@ 2020-03-17 8:06 ` Tom de Vries
2020-03-17 14:30 ` Simon Marchi
1 sibling, 0 replies; 6+ messages in thread
From: Tom de Vries @ 2020-03-17 8:06 UTC (permalink / raw)
To: gdb-patches
On 16-03-2020 18:59, Tom de Vries wrote:
> Hi,
>
> When running test-case gdb.linespec/cpcompletion.exp with target board
> unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, we run into lots of
> timeouts, in particular with this pattern:
> ...
> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
> cmd complete "b template2_"
> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
> tab complete "b template2_st" (timeout)
> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
> cmd complete "b template2_st"
> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
> tab complete "b template2_str" (timeout)
> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
> cmd complete "b template2_str"
> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
> tab complete "b template2_stru" (timeout)
> ...
>
> Fix this by detecting timeouts in test_complete_prefix_range_re and giving up
> after 3 consecutive timeouts.
>
> This reduces testing time from ~39m to ~9m.
>
> Tested on x86_64-linux.
>
> OK for trunk?
>
Um, sorry, I accidentally committed this patch. [ I used this patch to
shorten testing time for another patch and then committed both instead
of just that other patch. ]
I'll leave it in for now since it doesn't cause problems AFAICT, and
reverting will only cause noise, in case we keep it as is.
So, I'll wait for review comments to follow up on this, unless of course
someone objects.
Thanks,
- Tom
> [gdb/testsuite] Give up after consecutive timeouts in completion-support.exp
>
> ---
> gdb/testsuite/lib/completion-support.exp | 27 +++++++++++++++++++++++++--
> 1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/gdb/testsuite/lib/completion-support.exp b/gdb/testsuite/lib/completion-support.exp
> index 03959e4c7f..18eac827f5 100644
> --- a/gdb/testsuite/lib/completion-support.exp
> +++ b/gdb/testsuite/lib/completion-support.exp
> @@ -108,13 +108,19 @@ proc test_gdb_complete_tab_unique { input_line complete_line_re append_char_re }
>
> set test "tab complete \"$input_line\""
> send_gdb "$input_line\t"
> + set res 1
> gdb_test_multiple "" "$test" {
> -re "^$complete_line_re$append_char_re$" {
> pass "$test"
> }
> + timeout {
> + fail "$test (timeout)"
> + set res -1
> + }
> }
>
> clear_input_line $test
> + return $res
> }
>
> # Test that completing INPUT_LINE with TAB completes to "INPUT_LINE +
> @@ -242,7 +248,10 @@ proc test_gdb_complete_none { input_line } {
> proc test_gdb_complete_unique_re { input_line complete_line_re {append_char " "} {max_completions 0}} {
> set append_char_re [string_to_regexp $append_char]
> if { [readline_is_used] } {
> - test_gdb_complete_tab_unique $input_line $complete_line_re $append_char_re
> + if { [test_gdb_complete_tab_unique $input_line $complete_line_re \
> + $append_char_re] == -1 } {
> + return -1
> + }
> }
>
> # Trim INPUT_LINE and COMPLETE LINE, for the case we're completing
> @@ -266,6 +275,7 @@ proc test_gdb_complete_unique_re { input_line complete_line_re {append_char " "}
> }
>
> test_gdb_complete_cmd_unique $input_line $expected_output_re
> + return 1
> }
>
> # Like TEST_GDB_COMPLETE_UNIQUE_RE, but COMPLETE_LINE is a string, not
> @@ -301,9 +311,22 @@ proc test_complete_prefix_range_re {input completion_re start {end -1}} {
> set end [string length $input]
> }
>
> + set timeouts 0
> + set max_timeouts 3
> for {set i $start} {$i < $end} {incr i} {
> set line [string range $input 0 $i]
> - test_gdb_complete_unique_re "$line" $completion_re
> + set res [test_gdb_complete_unique_re "$line" $completion_re]
> + if { $res == -1 } {
> + incr timeouts
> + } else {
> + if { $timeouts > 0 } {
> + set timeouts 0
> + }
> + }
> + if { $timeouts == $max_timeouts } {
> + verbose -log "Consecutive timeouts in test_complete_prefix_range_re, giving up"
> + break
> + }
> }
> }
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH][gdb/testsuite] Give up after consecutive timeouts in completion-support.exp
2020-03-16 17:59 [PATCH][gdb/testsuite] Give up after consecutive timeouts in completion-support.exp Tom de Vries
2020-03-17 8:06 ` Tom de Vries
@ 2020-03-17 14:30 ` Simon Marchi
2020-03-17 14:53 ` Tom de Vries
1 sibling, 1 reply; 6+ messages in thread
From: Simon Marchi @ 2020-03-17 14:30 UTC (permalink / raw)
To: Tom de Vries, gdb-patches
On 2020-03-16 1:59 p.m., Tom de Vries wrote:
> Hi,
>
> When running test-case gdb.linespec/cpcompletion.exp with target board
> unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, we run into lots of
> timeouts, in particular with this pattern:
> ...
> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
> cmd complete "b template2_"
> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
> tab complete "b template2_st" (timeout)
> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
> cmd complete "b template2_st"
> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
> tab complete "b template2_str" (timeout)
> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
> cmd complete "b template2_str"
> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
> tab complete "b template2_stru" (timeout)
> ...
>
> Fix this by detecting timeouts in test_complete_prefix_range_re and giving up
> after 3 consecutive timeouts.
>
> This reduces testing time from ~39m to ~9m.
>
> Tested on x86_64-linux.
>
> OK for trunk?
>
> Thanks,
> - Tom
Hi Tom,
My only question is: why retry when we get a timeout?
If we get a timeout because GDB takes time to respond, then shouldn't the timeout
time be increased?
If we get a timeout because GDB doesn't respond the right thing, then shouldn't
we return immediately to avoid further timeouts, given the test has already failed?
Simon
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH][gdb/testsuite] Give up after consecutive timeouts in completion-support.exp
2020-03-17 14:30 ` Simon Marchi
@ 2020-03-17 14:53 ` Tom de Vries
2020-03-17 15:00 ` Simon Marchi
0 siblings, 1 reply; 6+ messages in thread
From: Tom de Vries @ 2020-03-17 14:53 UTC (permalink / raw)
To: Simon Marchi, gdb-patches
On 17-03-2020 15:30, Simon Marchi wrote:
> On 2020-03-16 1:59 p.m., Tom de Vries wrote:
>> Hi,
>>
>> When running test-case gdb.linespec/cpcompletion.exp with target board
>> unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, we run into lots of
>> timeouts, in particular with this pattern:
>> ...
>> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
>> cmd complete "b template2_"
>> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
>> tab complete "b template2_st" (timeout)
>> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
>> cmd complete "b template2_st"
>> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
>> tab complete "b template2_str" (timeout)
>> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
>> cmd complete "b template2_str"
>> FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
>> tab complete "b template2_stru" (timeout)
>> ...
>>
>> Fix this by detecting timeouts in test_complete_prefix_range_re and giving up
>> after 3 consecutive timeouts.
>>
>> This reduces testing time from ~39m to ~9m.
>>
>> Tested on x86_64-linux.
>>
>> OK for trunk?
>>
>> Thanks,
>> - Tom
>
> Hi Tom,
>
> My only question is: why retry when we get a timeout?
>
> If we get a timeout because GDB takes time to respond, then shouldn't the timeout
> time be increased?
>
> If we get a timeout because GDB doesn't respond the right thing, then shouldn't
> we return immediately to avoid further timeouts, given the test has already failed?
>
Well, here's how I reasoned.
Say for a string "abcdefgh" we test "a", "ab", "abc", etc.
If we timeout at "a", there is the change that it's f.i. specific to
one-letter matches, and such timeouts will not occur of "ab" and so on.
So, we try to establish a pattern: if "a", "ab" and "abc" timeout, then
we think there's a good chance that "abcd" will also timeout, and we
give up.
Having said that, my reasoning above is more concerned with not testing
too little. Your reasoning is more concerned with having less timeouts.
So I think both approaches are valid, they're just different trade-off
points.
I'm fine with submitting a follow up patch that gives up after the first
timeout, if you prefer that.
Thanks,
- Tom
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH][gdb/testsuite] Give up after consecutive timeouts in completion-support.exp
2020-03-17 14:53 ` Tom de Vries
@ 2020-03-17 15:00 ` Simon Marchi
2020-03-19 6:58 ` Tom de Vries
0 siblings, 1 reply; 6+ messages in thread
From: Simon Marchi @ 2020-03-17 15:00 UTC (permalink / raw)
To: Tom de Vries, gdb-patches
On 2020-03-17 10:53 a.m., Tom de Vries wrote:
> Well, here's how I reasoned.
>
> Say for a string "abcdefgh" we test "a", "ab", "abc", etc.
>
> If we timeout at "a", there is the change that it's f.i. specific to
> one-letter matches, and such timeouts will not occur of "ab" and so on.
>
> So, we try to establish a pattern: if "a", "ab" and "abc" timeout, then
> we think there's a good chance that "abcd" will also timeout, and we
> give up.
>
> Having said that, my reasoning above is more concerned with not testing
> too little. Your reasoning is more concerned with having less timeouts.
> So I think both approaches are valid, they're just different trade-off
> points.
>
> I'm fine with submitting a follow up patch that gives up after the first
> timeout, if you prefer that.
>
> Thanks,
> - Tom
>
Ok, that's fine with me.
Simon
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH][gdb/testsuite] Give up after consecutive timeouts in completion-support.exp
2020-03-17 15:00 ` Simon Marchi
@ 2020-03-19 6:58 ` Tom de Vries
0 siblings, 0 replies; 6+ messages in thread
From: Tom de Vries @ 2020-03-19 6:58 UTC (permalink / raw)
To: Simon Marchi, gdb-patches
[-- Attachment #1: Type: text/plain, Size: 964 bytes --]
On 17-03-2020 16:00, Simon Marchi wrote:
> On 2020-03-17 10:53 a.m., Tom de Vries wrote:
>> Well, here's how I reasoned.
>>
>> Say for a string "abcdefgh" we test "a", "ab", "abc", etc.
>>
>> If we timeout at "a", there is the change that it's f.i. specific to
>> one-letter matches, and such timeouts will not occur of "ab" and so on.
>>
>> So, we try to establish a pattern: if "a", "ab" and "abc" timeout, then
>> we think there's a good chance that "abcd" will also timeout, and we
>> give up.
>>
>> Having said that, my reasoning above is more concerned with not testing
>> too little. Your reasoning is more concerned with having less timeouts.
>> So I think both approaches are valid, they're just different trade-off
>> points.
>>
>> I'm fine with submitting a follow up patch that gives up after the first
>> timeout, if you prefer that.
>>
>> Thanks,
>> - Tom
>>
>
> Ok, that's fine with me.
Here is that follow-up patch.
OK for trunk?
Thanks,
- Tom
[-- Attachment #2: 0001-gdb-testsuite-Bail-out-after-1-timeout-in-test_complete_prefix_range_re.patch --]
[-- Type: text/x-patch, Size: 1445 bytes --]
[gdb/testsuite] Bail out after 1 timeout in test_complete_prefix_range_re
In test_complete_prefix_range_re we stop testing the range after 3 consecutive
timeouts.
Handle timeouts more rigorously by stopping testing after the first timeout.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-03-19 Tom de Vries <tdevries@suse.de>
* lib/completion-support.exp (test_complete_prefix_range_re): Stop
testing after the first timeout.
---
gdb/testsuite/lib/completion-support.exp | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/gdb/testsuite/lib/completion-support.exp b/gdb/testsuite/lib/completion-support.exp
index 18eac827f5..2bf3acd1f4 100644
--- a/gdb/testsuite/lib/completion-support.exp
+++ b/gdb/testsuite/lib/completion-support.exp
@@ -311,20 +311,11 @@ proc test_complete_prefix_range_re {input completion_re start {end -1}} {
set end [string length $input]
}
- set timeouts 0
- set max_timeouts 3
for {set i $start} {$i < $end} {incr i} {
set line [string range $input 0 $i]
set res [test_gdb_complete_unique_re "$line" $completion_re]
if { $res == -1 } {
- incr timeouts
- } else {
- if { $timeouts > 0 } {
- set timeouts 0
- }
- }
- if { $timeouts == $max_timeouts } {
- verbose -log "Consecutive timeouts in test_complete_prefix_range_re, giving up"
+ verbose -log "Timeout in test_complete_prefix_range_re, giving up"
break
}
}
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-03-19 6:58 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-16 17:59 [PATCH][gdb/testsuite] Give up after consecutive timeouts in completion-support.exp Tom de Vries
2020-03-17 8:06 ` Tom de Vries
2020-03-17 14:30 ` Simon Marchi
2020-03-17 14:53 ` Tom de Vries
2020-03-17 15:00 ` Simon Marchi
2020-03-19 6:58 ` Tom de Vries
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox