[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