From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id sC7xF8fcYGq2pCUAWB0awg (envelope-from ) for ; Wed, 22 Jul 2026 11:07:51 -0400 Received: by simark.ca (Postfix, from userid 112) id 51F0B1E09E; Wed, 22 Jul 2026 11:07:51 -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 [IPv6:2620:52:6:3111::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 94F7E1E033 for ; Wed, 22 Jul 2026 11:07:50 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C09D34BA2E07 for ; Wed, 22 Jul 2026 15:07:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C09D34BA2E07 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by sourceware.org (Postfix) with ESMTPS id 301AB4BA2E07 for ; Wed, 22 Jul 2026 15:07:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 301AB4BA2E07 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 301AB4BA2E07 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=209.85.221.46 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784732844; cv=none; b=vKO6msWJAUMGX0FY8LTCirqxygIGxYNl4SZMLVyXYInv06SZwQ6WvpDWtnlDjbh9qKdeCNwyEQ1MHp5EPcz0HybluxCDRDpLVqXdbgrqdYAE65i2ooBcvkA+yBRqhlunwD27Uo5ESlsPCnwe31IXo6KWEeWfy6XBPcqWeuXoJYo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784732844; c=relaxed/simple; bh=4FBPrYcEt+hNZsF3WX+PGTftOZIgfDsFhcPj/xWHc70=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=sEHMu3OZDex1MOcaRrluLrmk9psfKxzY4OF3FPGcVC8pHnufRqc81gA+chOFcrMpb+DnzoZPDrPkO3E/PkCm5hz5hEtYndDecrTaLpijdc9gQTmx/f2iWdqKy7F79+JI73FFtzdsgJdOUyGJRyODyX32rBz0FzXFHnkHCEZNeU0= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 301AB4BA2E07 Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-47db714766aso3693841f8f.0 for ; Wed, 22 Jul 2026 08:07:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784732843; x=1785337643; h=content-transfer-encoding:content-type:in-reply-to:content-language :from:references:cc:to: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=1Xjjx+ZlO5LmOfcIeItvVB27+Cbi2/xheW3vTq99vw8=; b=MBGNE17aM9Z17MgmGGMARAmqblmTQTk2vPIFrmkYAOYV+Kqw5KLFnmFkUYkJpUO6N0 25ahzzKsCG+lvAI1N+U2aBk3JvdmajQDSvoLoKe6I3SY3QYqWXqmC2ytqn7JJ7c9ygbY GxaRX5GefXcpfiVdhJKXpJgOEwMZrL/Rj7wCvmWHPFjaZWsQ00rMJsCrqulChM1YgjbS wrDhUgZb3jO4qoPFZ3pP+KtkiOkTaLp4SkWQc9U2O09W3CZMvW4WN6WVmrJ50ZyrhYks TVx0JIo67d7IDD6v+tdfOHC7X40FLQa4L/6TGYDD+mW+1H9OIjW+AMOKS+ydj3/ropnk uWLQ== X-Gm-Message-State: AOJu0YyKVOz9RRcdGMJzJItJ4Pr2dSsyy/BKbn4vYwaSH2lqKk7kE1Jd R6SEnkFyZc5NC4D5RIzGaUyrTgXujDZbOc5zNl4jlht80UM8MV6JOtvM X-Gm-Gg: AR+sD11Rszlb5aJHfCIuFhKyAAtQw1J/7eL557GSmbUdC7XO2xm3C7GvIEJg4AzFD8b tveM3mXD0gW+HWQ/cpVOUizPgsrmGVnMnl8zLL/DUZuMyXvvZU6otrsVRtloR5jH3bXXze6aGwT njcOJQGvVolFxDJml6yW9Qe4WQEnE+Wdh+IqKMKLA9ged3Vc9c/T7qxbUhq/G3sN3E0KnWLwk/e VkPCdhn4YW1KixRp9LyHpde+Ys7xxalZtF3hFdNbObEiKakazmfnfDBuD8bL/p8MQqq+BHwfcra brr1TTOwBaYeZHDLsM1oK76oczHQKPHInY2r0MMM6Sz826x3/DQC8OMwPpmNXV1PtvBa1rxKuFo uu8/F8vnxL+9Mv/s8ppNXOhGzdTjbWPseyvwlRpzPSnNXFLmd99zIxI8kFP7Oukw5bqouos6Ens 0IKONU5KOAYoAQc9kPw8muyKYrNEjKqieRqB8wAp5+U+s2 X-Received: by 2002:a05:6000:26c6:b0:47a:b6a0:b024 with SMTP id ffacd0b85a97d-47f840a020dmr5836454f8f.4.1784732842631; Wed, 22 Jul 2026 08:07:22 -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 ffacd0b85a97d-47f864305f5sm6243009f8f.17.2026.07.22.08.07.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Jul 2026 08:07:22 -0700 (PDT) Message-ID: <1b0c5cae-df37-4bad-bb77-51464b80cf88@palves.net> Date: Wed, 22 Jul 2026 16:07:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Windows: Fix set_unbuffered_mode.o file rename race To: Tom Tromey Cc: gdb-patches@sourceware.org References: <20260709155657.412594-1-pedro@palves.net> <87cxwgwax3.fsf@tromey.com> From: Pedro Alves Content-Language: en-US In-Reply-To: <87cxwgwax3.fsf@tromey.com> 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-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. Thanks again, Pedro Alves >From 81a1c8f753e506b3890db4b1254df05aa67a0230 Mon Sep 17 00:00:00 2001 From: Pedro Alves 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 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