From: Pedro Alves <pedro@palves.net>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Windows: Fix set_unbuffered_mode.o file rename race
Date: Wed, 22 Jul 2026 16:07:17 +0100 [thread overview]
Message-ID: <1b0c5cae-df37-4bad-bb77-51464b80cf88@palves.net> (raw)
In-Reply-To: <87cxwgwax3.fsf@tromey.com>
On 2026-07-21 17:43, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <pedro@palves.net> 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 <tom@tromey.com>
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.
Thanks again,
Pedro Alves
From 81a1c8f753e506b3890db4b1254df05aa67a0230 Mon Sep 17 00:00:00 2001
From: Pedro Alves <pedro@palves.net>
Date: Fri, 28 Nov 2025 11:28:06 +0000
Subject: [PATCH] Windows: Fix set_unbuffered_mode.o file rename race
The atomic file rename for set_unbuffered_mode.o can fail in this scenario:
| process A | process B |
|---------------------------------+---------------------------|
| compiles temp .o | compiles temp .o |
| moves .o | |
| links with .o file (locks file) | moves .o (fails w/ EBUSY) |
Here's what it looks like:
builtin_spawn -ignore SIGHUP /mingw64/bin/clang -fdiagnostics-color=never -Wno-unknown-warning-option -w -c -o /c/msys2/home/alves/gdb/build-testsuite/temp/53930/set_unbuffered_mode-c.o /c/rocgdb/src/gdb/testsuite/lib/set_unbuffered_mode.c
pid is 54259 -54259
pid is -1
output is status 0
ERROR: tcl error sourcing /c/rocgdb/src/gdb/testsuite/gdb.base/step-over-no-symbols.exp.
ERROR: tcl error code POSIX EBUSY {file busy}
ERROR: error renaming "/c/msys2/home/alves/gdb/build-testsuite/temp/53930/set_unbuffered_mode.o" to "/c/msys2/home/alves/gdb/build-testsuite/set_unbuffered_mode.o": file busy
while executing
"file rename -force -- $unbuf_obj $gdb_saved_set_unbuffered_mode_obj"
(procedure "gdb_compile" line 559)
invoked from within
"gdb_compile $source $dest $type $options"
(procedure "gdb_compile" line 42)
invoked from within
"$func $objects "${binfile}" executable $options"
(procedure "build_executable_from_specs" line 50)
invoked from within
"build_executable_from_specs {*}$arglist"
(procedure "build_executable" line 11)
invoked from within
"build_executable "failed to build" ${testfile} $srcfile"
(file "/c/rocgdb/src/gdb/testsuite/gdb.base/step-over-no-symbols.exp" line 21)
invoked from within
"source /c/rocgdb/src/gdb/testsuite/gdb.base/step-over-no-symbols.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /c/rocgdb/src/gdb/testsuite/gdb.base/step-over-no-symbols.exp"
invoked from within
"catch "uplevel #0 source $test_file_name" msg"
UNRESOLVED: gdb.base/step-over-no-symbols.exp: testcase '/c/rocgdb/src/gdb/testsuite/gdb.base/step-over-no-symbols.exp' aborted due to Tcl error
If we get EBUSY, it's because another parallel worker already managed
to build and move its set_unbuffered_mode.o copy to the final
destination. So fix it by simply ignoring EBUSY.
gdb_windows_manifest_obj has similar code with the same problem, so
put the atomic rename in a new file_rename_atomic procedure, and use
it from both places.
(Note: both the set_unbuffered_mode.o path and
gdb_windows_manifest_obj are Windows-specific.)
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I6a32d17364a19337d7f55e4376de736e1cca799d
---
gdb/testsuite/lib/gdb.exp | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 9b86d53be08..41e9a8c721e 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -6408,6 +6408,25 @@ proc quote_for_host { args } {
return $str
}
+# Rename SRC to DST, ignoring EBUSY. This is used when multiple
+# parallel workers all want to rename their copy of SRC to DST, as an
+# atomic commit, and it doesn't matter which one wins, as all the
+# copies are identical.
+proc file_rename_atomic {src dst} {
+ set rc [catch { file rename -force -- $src $dst } err opts]
+
+ if {$rc} {
+ set code [dict get $opts -errorcode]
+ if {[llength $code] >= 2 && [lindex $code 1] eq "EBUSY"} {
+ # Normal parallel race loss.
+ } else {
+ error $err $opts
+ }
+ }
+
+ return $rc
+}
+
# Set while linker_supports_manifest_embed is running its test link,
# so that the inner gdb_compile that link goes through skips the
# manifest-embedding logic and doesn't recurse back into the probe.
@@ -6491,7 +6510,7 @@ proc gdb_windows_manifest_obj {} {
if {[info exists ::GDB_PARALLEL]} {
# Make sure to write the .o file atomically. (Note
# GDB_PARALLEL mode does not support remote host testing.)
- file rename -force -- $obj $saved
+ file_rename_atomic $obj $saved
} else {
remote_download host $obj $saved
}
@@ -7019,7 +7038,7 @@ proc gdb_compile {source dest type options} {
# Make sure to write the .o file atomically.
# (Note GDB_PARALLEL mode does not support remote
# host testing.)
- file rename -force -- $unbuf_obj $gdb_saved_set_unbuffered_mode_obj
+ file_rename_atomic $unbuf_obj $gdb_saved_set_unbuffered_mode_obj
} else {
remote_download host $unbuf_obj $gdb_saved_set_unbuffered_mode_obj
}
base-commit: 33f0797fff4dcac33092bfde19105c1eeb483526
--
2.54.0
next prev parent reply other threads:[~2026-07-22 15:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 15:56 Pedro Alves
2026-07-21 16:43 ` Tom Tromey
2026-07-22 15:07 ` Pedro Alves [this message]
2026-07-22 15:20 ` [PATCH] gdb/testsuite: Use file_rename_atomic in gdb_do_cache too Pedro Alves
2026-07-22 15:50 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1b0c5cae-df37-4bad-bb77-51464b80cf88@palves.net \
--to=pedro@palves.net \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox