[PATCH] gdb/testsuite: Use file_rename_atomic in gdb_do_cache too

Pedro Alves <[email protected]> Wed, 22 Jul 2026 16:20:49 +0100
Newsgroups gmane.comp.gdb.patches
Message-ID <[email protected]>
On 2026-07-22 16:07, Pedro Alves wrote:
> On 2026-07-21 17:43, Tom Tromey wrote:
>>>>>>> "Pedro" == Pedro Alves <[email protected]> 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 <[email protected]>
> 
> 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 <[email protected]>
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