From: Tom de Vries <tdevries@suse.de>
To: Simon Marchi <simark@simark.ca>, gdb-patches@sourceware.org
Subject: Re: [PATCH][gdb/testsuite] Give up after consecutive timeouts in completion-support.exp
Date: Tue, 17 Mar 2020 15:53:44 +0100 [thread overview]
Message-ID: <5ffff0ef-e2f6-82ea-306c-a661e9ae830c@suse.de> (raw)
In-Reply-To: <e85ec950-8627-0eaf-f122-17c66b2d67f3@simark.ca>
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
next prev parent reply other threads:[~2020-03-17 14:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-16 17:59 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 [this message]
2020-03-17 15:00 ` Simon Marchi
2020-03-19 6:58 ` Tom de Vries
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=5ffff0ef-e2f6-82ea-306c-a661e9ae830c@suse.de \
--to=tdevries@suse.de \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.ca \
/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