cmd/cgo/internal/test: consistently failing with `segmentation fault` on `linux-arm-aws` since CL 545277

[bcmills]

Go version

b2efd1d

What operating system and processor architecture are you using (go env)?

linux-arm-aws at b2efd1de97402ec4b8fb4e9e0ec29c8e49e8e200


##### Test execution environment.
# GOARCH: arm
# CPU: ARMv8 Processor rev 1 (v8l)
# GOOS: linux
# OS Version: Linux 4.19.0-12-arm64 #1 SMP Debian 4.19.152-1 (2020-10-18) armv8l

What did you do?

https://build.golang.org/log/4023a6ee5a18667fe161b4b917a1a0c4579527d8

What did you expect to see?

Passing tests.

What did you see instead?

##### Testing cgo
ok  	cmd/cgo/internal/test	0.916s
ok  	cmd/cgo/internal/test	0.880s
ok  	cmd/cgo/internal/testtls	0.005s
ok  	cmd/cgo/internal/testtls	0.003s
ok  	cmd/cgo/internal/testnocgo	0.004s
ok  	cmd/cgo/internal/testnocgo	0.003s
signal: segmentation fault
FAIL	cmd/cgo/internal/test	0.521s

[dmitshur]

CC @mknyszek, @golang/compiler.

[mknyszek]

This doesn't make any sense to me... That CL should be totally unrelated to this test. I'll investigate.

[mknyszek]

I can't reproduce by running the tests cmd/cgo/internal/test tests directly via go tool dist test on a gomote. I tried all variants, including the ones that fall under the ##### Testing cgo heading. Trying run.bash.

[mknyszek]

Yep, I can't reproduce at all on a linux-arm-aws gomote. I do not know how to proceed here. :(

[cherrymui]

This reminds me #61514, which I also don't understand and it magically stopped...

[mknyszek]

Yeah, that seems like exactly the same issue to me.

[bcmills]

Possibly something relating to code or data alignment changing in the compiled binary?
(I'm thinking of something along the general lines of #60825.)

[cherrymui]

It is possible that this triggers some bug that is very sensitive to how the binary is laid out. For #61514, I couldn't reproduce on gomote or anything other than pre-/post-submit builds, and the test doesn't print anything besides segmentation fault, which makes debugging very hard, though.

[bcmills]

@mknyszek, looking back at successful runs (https://build.golang.org/log/4cad61d2d6f9b3b16aa53609780318e36b984a8c) to work around #51050, I see some environment variables that might be relevant:
"GOARM=6" "GOHOSTARCH=arm" "CGO_CFLAGS=-march=armv6" "CGO_LDFLAGS=-march=armv6" (set from here).

Maybe the difficultly reproducing the problem with go tool dist test comes down to an environment setting?