From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1677864178; bh=YvEboLJlamC/XqH+wl0OwVM6Rc2E9jKfWVXbVY0I404=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=C/SYqpBOTwbyqaCQH6QKG/PIVPsK0iwIFRIKZvlLUYif6BTeGHVE/9izjzVn93OMZ KhDLLln2z847T4wPOvrqU8goBylJbSZc3TktGmj2TtWMEukKEz5Cmhd7hR1PMIuHW9 Evp9t32zmmZsS8KgVGWrqI6ailHGnDeHc0lly3DQ= 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> From: Simon Marchi In-Reply-To: <87o7p9aitj.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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