Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/build: linux-arm trybot failure #35628

Open
cherrymui opened this issue Nov 15, 2019 · 3 comments
Assignees
Labels
Milestone

Comments

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Nov 15, 2019

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

tip (d856e05)

What did you do?

Run linux-arm trybot on tip (with a dummy change, CL https://go-review.googlesource.com/c/go/+/207440)
It failed with https://storage.googleapis.com/go-build-log/09ec0769/linux-arm_4add410f.log

I also got a few failures on a different CL (https://go-review.googlesource.com/c/go/+/207350)
https://storage.googleapis.com/go-build-log/3c197532/linux-arm_4a2eca13.log
https://storage.googleapis.com/go-build-log/3c197532/linux-arm_e2868c28.log
https://storage.googleapis.com/go-build-log/3472bd16/linux-arm_0d7459e0.log

I cannot reproduce it with gomote. Also the linux-arm builder is happy.

I think it may be related to that the trybot does a cross-compilation and then ships the binaries to the ARM machine.

cc @bradfitz

@gopherbot gopherbot added this to the Unreleased milestone Nov 15, 2019
@gopherbot gopherbot added the Builders label Nov 15, 2019
@bradfitz

This comment has been minimized.

Copy link
Member

@bradfitz bradfitz commented Nov 15, 2019

I suspect this was "broken" by https://go-review.googlesource.com/c/build/+/205603 which upgraded the ARM environment (where tests run) to Buster, but the compilation half on x86 was unchanged.

I say "broken" in quotes because this was never a problem until slowbots which let you do this again.

But it used to work with trybots on by default a few years ago, so it does work if we configure both halves the same.

Will fix.

@bradfitz bradfitz self-assigned this Nov 15, 2019
@cherrymui

This comment has been minimized.

Copy link
Contributor Author

@cherrymui cherrymui commented Nov 15, 2019

Thanks @bradfitz

@bradfitz

This comment has been minimized.

Copy link
Member

@bradfitz bradfitz commented Nov 16, 2019

Hmm, this isn't as obvious as I'd hoped.

Both environments are Debian buster:

Cross-compilation:
https://github.com/golang/build/blob/master/env/crosscompile/linux-armhf-cross/Dockerfile

Linux-arm on Scaleway:
https://github.com/golang/build/blob/master/env/linux-arm/scaleway/Dockerfile

@rsc, you probably remember me debugging similar issues in the past. I'd love some better tooling to help debug these sorts of issues. It doesn't affect many people, though. But if we could do this sort of cross-compilation (make.bash in one place, run tests elsewhere) for more builders (riscv, mips, arm, etc) we could get much better throughput from our slower builders. But I'm always scared of doing it due to issues like this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.