Does this issue reproduce with the latest release?
What did you do?
Interrupt a build with ^C
Make some changes that cause our build system to attempt to rebuild the binary (like git rebase)
Run the build
What did you expect to see?
What did you see instead?
go build go.fuchsia.dev/fuchsia/tools/fidl/fidlmerge: build output "../../../../fidlmerge" already exists and is not an object file
Upon inspection, the file starts with 4KB of 0x00s, which definitely isn't an object file. But the block of the file at 0x1000 does match the contents of the file that's written by the compiler if I delete the "bad" file and re-run the build.
The text was updated successfully, but these errors were encountered:
The 4KB of zeros could be related to #53804 (which is a kernel bug as far as we understand). But this issue is about interrupting a build with ctrl-C, which leaves more uncertainty and could result in a corrupted file in other ways.
I think this issue is more about whether the go command should emit an error for an existing non-object output file (possibly due to corruption)? If so, this would be working as intended.
As a user, it seems like the wrong behavior for the go tool to be unable to build if there is an output file that it created (even if invalid due to an interrupted build). Ideally, it wouldn't leave the file in an invalid state on cancellation (^C).
changed the title
'build output "...." already exists and is not an object file' error after interrupted compilationDec 5, 2022