From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <simark@simark.ca>
Received: from simark.ca (simark.ca [158.69.221.121])
 by sourceware.org (Postfix) with ESMTPS id 34B353871029
 for <gdb-patches@sourceware.org>; Tue, 17 Mar 2020 14:30:13 +0000 (GMT)
Received: from [10.0.0.11] (unknown [192.222.164.54])
 (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by simark.ca (Postfix) with ESMTPSA id 1894F1E5FD;
 Tue, 17 Mar 2020 10:30:12 -0400 (EDT)
Subject: Re: [PATCH][gdb/testsuite] Give up after consecutive timeouts in
 completion-support.exp
To: Tom de Vries <tdevries@suse.de>, gdb-patches@sourceware.org
References: <20200316175925.GA5989@delia>
From: Simon Marchi <simark@simark.ca>
Message-ID: <e85ec950-8627-0eaf-f122-17c66b2d67f3@simark.ca>
Date: Tue, 17 Mar 2020 10:30:11 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200316175925.GA5989@delia>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US-large
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=0.0 required=5.0 tests=KAM_DMARC_STATUS, SPF_HELO_PASS,
 SPF_PASS autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gdb-patches@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org>
List-Unsubscribe: <http://sourceware.org/mailman/options/gdb-patches>,
 <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe>
List-Archive: <http://sourceware.org/pipermail/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help>
List-Subscribe: <http://sourceware.org/mailman/listinfo/gdb-patches>,
 <mailto:gdb-patches-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Mar 2020 14:30:14 -0000

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