cmd/go: 'build output "...." already exists and is not an object file' error after interrupted compilation

[woody77]

What version of Go are you using (go version)?

$ go version
go version go1.19.3 linux/amd64

Does this issue reproduce with the latest release?

Unknown.

What did you do?

Rough steps:

0. Interrupt a build with ^C
1. Make some changes that cause our build system to attempt to rebuild the binary (like git rebase)
2. Run the build

What did you expect to see?

No error.

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.

[woody77]

The only workaround seems to be to delete the output file and try again.

[seankhliao]

is this using the go tool or bazel ?

[bcmills]

Possibly related to #53804 (CC @golang/compiler)?

[tamird]

Yes, looks related. This is using the go tool.

[cherrymui]

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.

[woody77]

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).

[iholder101]

Thanks @woody77.
The issue had reproduced for me as well, thanks for aiming to fix it.

EDIT: I confirm that deleting the file solves the problem