From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wUSgKPHfYGq/siUAWB0awg (envelope-from ) for ; Wed, 22 Jul 2026 11:21:21 -0400 Received: by simark.ca (Postfix, from userid 112) id A37E81E033; Wed, 22 Jul 2026 11:21:21 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id E4B721E033 for ; Wed, 22 Jul 2026 11:21:20 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 70FCF4BA23CA for ; Wed, 22 Jul 2026 15:21:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 70FCF4BA23CA Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by sourceware.org (Postfix) with ESMTPS id 599244BA2E07 for ; Wed, 22 Jul 2026 15:20:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 599244BA2E07 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 599244BA2E07 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=209.85.128.50 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784733657; cv=none; b=kAK2m6JyCYosD0yPsEvLcKDnRzOkNWLxMcbxmeXVEdnvSYp5cCq4MOOZCWR/H1i4J0/1J8kWsepzjrtxjZI/Gey69qvzQ9/xsckCZQMuPXCws3ZgLscopmeqg4FbFcMBsobhbDifpxQkF4pI8mVAaCfd+CVGckr142GD/B/GuVY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784733657; c=relaxed/simple; bh=mOsxlIu4u20+1+ftFiMHeU74wwzHcVpWyYDk7vkzssE=; h=Message-ID:Date:MIME-Version:Subject:From:To; b=eN7GVlY2YLzVJZ2STF1zRL0vI88RD94u8hzU+gHX+Mkce/Tn+NAUIv1o5SivW9japhn5CszvRCTi0Z9DTtTgHFp1q7cnz+HCqvOqhVQHV1nXoi8xAoVeIRVvLeD7JNOQguSs+R9yipoje58lRRhJgzqPpL7jduWrMRGsZVKGGqg= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 599244BA2E07 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-495635a85d2so26622865e9.0 for ; Wed, 22 Jul 2026 08:20:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784733656; x=1785338456; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=01WoT9A9ESZUclZB9pqUgWzeil7j4s3umTtu7PFFvOU=; b=gxee4fhFnBJE/CL73ezkVGXeQJ/xkkJpHjt5hQkv/ZaXrDZ/QqTVkwYLzpOmbHRRkz R9z040+Q46qwuHHKxIqILXJu7QcW88xFGEh9euI16dEVPyJXRm1xzjq9lvO37uovleJy 4lGsB42/EtOPVZpFjiCGPFentW6Rd9cyn1Kv41ZCsQyVyqUoM644TlyC5zI6+xhYLpen fmUd5kqmq8qlO9ZVDAYHZy0C/a6ufF/nQKBkDBryN8VrnthU7TmSXOLKCRbYzySgQ+O3 CfR57EM08xnY3mOPJuzQnj6SqBl2ibHOIKF4+Pw452be/GIthaCi09yAPo7wVrAbAACH fgCg== X-Gm-Message-State: AOJu0Yw4DYpm1vJjeOrZLf/WKEulLARVZfIs+8mVTP7ilLYDzMTz9jbL zv/2kCO9LBMZrIiPyPsvq8HT/JUsKP9OaezsttvDNEjzdG3dcvZ8p+hMZy2m/rin X-Gm-Gg: AR+sD10Lc+TJ+UV91Ytuw1Tvvqcn4I4MJOdHAV9Kb8K7ejMyTSMfM0VdvPByRtmBX8A E8eXLRdz9AxX8v5366pQ4ub7i0ae9UN4k+jXQ8FU9GI+kPnpACU9X115ZIs9zlNBCiUEBDwErJa k09mD4Wl10baYkKveRP6O53axqqHh8wPwGYn/85+TMYVja4XiIG2oLKeFJc/gCf9yLOrtTP6xPv lZTqrc2YpaXNcOo8Jx0YWnXAjMEV/eeSlWpEBebHHMGemlXON7adxxWrX7zkz2keLOpcZ+ObFXp B39I4v8qXjK7QOLLYQiDoKeYWC8YgFVvLB2v8s1bR3/UNeXAct08sooh4bNe9EK9Xh9beENj0QR u5tOTdzoT8MWCdNJ1HFKmKjxH69ZWSph35PqXg2VdZ04UDwCuJNq3HpwtK7ieW+yTZwbNwtqYwd 7Q+GQf7Qbg2EtnYwRCM3qn/Ftyk8hT6cFvwl+Haa8yg/7c X-Received: by 2002:a05:600c:5698:b0:493:f78f:cd70 with SMTP id 5b1f17b1804b1-4954a405ec6mr208478855e9.18.1784733656032; Wed, 22 Jul 2026 08:20:56 -0700 (PDT) Received: from ?IPV6:2001:8a0:fae3:3700:29ae:9c1e:45d9:1a25? ([2001:8a0:fae3:3700:29ae:9c1e:45d9:1a25]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4956537c6besm143849595e9.8.2026.07.22.08.20.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Jul 2026 08:20:55 -0700 (PDT) Message-ID: Date: Wed, 22 Jul 2026 16:20:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH] gdb/testsuite: Use file_rename_atomic in gdb_do_cache too From: Pedro Alves To: Tom Tromey Cc: gdb-patches@sourceware.org References: <20260709155657.412594-1-pedro@palves.net> <87cxwgwax3.fsf@tromey.com> <1b0c5cae-df37-4bad-bb77-51464b80cf88@palves.net> Content-Language: en-US In-Reply-To: <1b0c5cae-df37-4bad-bb77-51464b80cf88@palves.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 2026-07-22 16:07, Pedro Alves wrote: > On 2026-07-21 17:43, Tom Tromey wrote: >>>>>>> "Pedro" == Pedro Alves writes: >> >> Pedro> If we get EBUSY, it's because another parallel worker already managed >> Pedro> to build and move its set_unbuffered_mode.o copy to the final >> Pedro> destination. So fix it by simply ignoring EBUSY. Put the rename in >> Pedro> its own procedure, as I expect this will be used in more places. >> >> This looks ok to me, thanks. >> Approved-By: Tom Tromey > > Thank you. Meanwhile, the manifest patch went in, which adds another path doing > the exact same, which needs the same fix. I did the obvious tweak to the patch > to call the new proc from two places, and merged it, as below. After merging, I recalled that Claudiu mentioned that he was seeing EBUSY errors in the caching code too. For some reason, probably just "lucky" timing, I don't recall seeing it trigger on my machine, but looking at the code, the pattern is clear, and the fix becomes pretty obvious, I think -- just another spot that should use file_rename_atomic. I grepped for "file rename" and didn't see any other spot that might need this. >From 1b1e6c373467a889bc91499cf49fa874bd92a2bc Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Wed, 22 Jul 2026 16:08:55 +0100 Subject: [PATCH] gdb/testsuite: Use file_rename_atomic in gdb_do_cache too An earlier commit ("Windows: Fix set_unbuffered_mode.o file rename race") introduced file_rename_atomic to ignore EBUSY when multiple parallel workers race to rename their identical copy of a file to a shared final destination, and converted the two atomic renames in gdb.exp to use it. gdb_do_cache in cache.exp does the same thing: in GDB_PARALLEL mode, each worker writes the results cache to a per-pid temporary file and then atomically renames it into place, so it can hit the same EBUSY race on Windows. It was missed by that commit. Fix it by using file_rename_atomic there too. Change-Id: I9780ed4989f9c4e9daf7143280cd63a65c6918ed --- gdb/testsuite/lib/cache.exp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/testsuite/lib/cache.exp b/gdb/testsuite/lib/cache.exp index 1ba8c881716..1e2d470773a 100644 --- a/gdb/testsuite/lib/cache.exp +++ b/gdb/testsuite/lib/cache.exp @@ -262,7 +262,7 @@ proc gdb_do_cache {name args} { puts $fd $gdb_data_cache(${cache_name},exit) puts $fd $gdb_data_cache(${cache_name},also_called) close $fd - file rename -force -- $cache_filename.[pid] $cache_filename + file_rename_atomic $cache_filename.[pid] $cache_filename } gdb_cache_maybe_gdb_exit $name $gdb_data_cache(${cache_name},exit) \ $gdb_data_cache(${cache_name},also_called) base-commit: 81a1c8f753e506b3890db4b1254df05aa67a0230 -- 2.54.0