From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id UZh0DQgtAmRvdQMAWB0awg (envelope-from ) for ; Fri, 03 Mar 2023 12:23:20 -0500 Received: by simark.ca (Postfix, from userid 112) id 289C71E223; Fri, 3 Mar 2023 12:23:20 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=p1SbWHDj; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 57BDB1E128 for ; Fri, 3 Mar 2023 12:23:19 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 68C2F3858439 for ; Fri, 3 Mar 2023 17:23:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 68C2F3858439 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1677864198; bh=2ap4E3ZUewAgReA88LDHffIp7E+ZTECimWs1FSw2gy0=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=p1SbWHDjKT7pDg+FI050EUCfBCdPkb2+x8wLvK6KsUQcUPWjdpzG9VUdEC9yViVEG SwjSvTyT+vFuZiTgCgxAt3mEpgx1NmJj+qiMl6udWY4Xu3RtERm7hB0C/ghF5yozKA tG/ylnbme8DClDpQ5+e1LezOUFK1QPya2MMtMUf4= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 4D6BF3858D37 for ; Fri, 3 Mar 2023 17:22:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4D6BF3858D37 Received: from [172.16.0.192] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (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 895C41E128; Fri, 3 Mar 2023 12:22:58 -0500 (EST) Message-ID: <80c09fa0-76f3-2625-d991-fdce471c71a9@simark.ca> Date: Fri, 3 Mar 2023 12:22:58 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v3 0/2] Write DWARF index cache files in background Content-Language: fr To: Tom Tromey Cc: Tom Tromey via Gdb-patches References: <20221219164558.378363-1-tromey@adacore.com> <87k006j3zz.fsf@tromey.com> <1154aa3c-4ef9-80ef-c551-35a9ce8bf294@simark.ca> <87o7p9aitj.fsf@tromey.com> In-Reply-To: <87o7p9aitj.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 3/3/23 11:41, Tom Tromey wrote: > Simon> FAIL: gdb.base/index-cache.exp: test_cache_enabled_miss: at least one file was created > Simon> FAIL: gdb.base/index-cache.exp: test_cache_enabled_miss: expected file is there > > I can't reliably reproduce this. > > However, I believe the problem is that because the cache file is written > in the background, the test is racy. Ok, thanks for the tip. It should be possible to reliably reproduce it with that change then, which makes GDB take more time to write the index: diff --git a/gdb/dwarf2/index-write.c b/gdb/dwarf2/index-write.c index 62c2cc6ac7de..d3bad4aaa0c9 100644 --- a/gdb/dwarf2/index-write.c +++ b/gdb/dwarf2/index-write.c @@ -1485,6 +1485,7 @@ write_dwarf_index (dwarf2_per_bfd *per_bfd, const char *dir, (dwz_index_wip.has_value () ? dwz_index_wip->out_file.get () : NULL)); + sleep(3); objfile_index_wip.finalize (); if (dwz_index_wip.has_value ()) > I think the appended should fix it. This just mirrors something done in > test_cache_enabled_hit, and the idea is that waiting for gdb to exit > ensures that the cache file will have been written. > > Tom > > diff --git a/gdb/testsuite/gdb.base/index-cache.exp b/gdb/testsuite/gdb.base/index-cache.exp > index 0614d4ee2db..d9a6145b5df 100644 > --- a/gdb/testsuite/gdb.base/index-cache.exp > +++ b/gdb/testsuite/gdb.base/index-cache.exp > @@ -157,6 +157,9 @@ proc_with_prefix test_cache_enabled_miss { cache_dir } { > > lassign [ls_host $cache_dir] ret files_before > > + # Just to populate the cache. > + run_test_with_flags $cache_dir on {} > + > run_test_with_flags $cache_dir on { > > lassign [ls_host $cache_dir] ret files_after I don't understand this. The first run_test_with_flags will populate the cache, so the second run will use the cache and be a cache hit. The tests that checks that the expected file is there will work. But the check_cache_stats test will operate the GDB that will have had a cache hit, so we won't get the expected result (a cache miss). I think this could be solved with a maintenance command to explicitly wait for index cache creation (calls wait_for_index_cache). I don't see another reliable way. What do you think? I can implement it if you think it would work. Simon