I found similar failures on the more reliable android/arm64 builders:

http://build.golang.org/log/10e13869523708ea0968eb6fc2d8c0871a55825a
http://build.golang.org/log/102819b526620f5699bb1bbaba795271ada8f462
http://build.golang.org/log/767c37d013529f5d76b1c018f3f4c6710469aaee

I haven't seen anything on the android/386, android/arm nor on linux/arm64, which reminds me of physical page size issues like #9993 (according to #11886 the linux/arm64 builder is using 4k pages).

cc @aclements @randall77

The android/arm64 ones are all in TestStackBarrierProfiling, which uses a funny debug mode that may simply be broken on arm64 (it's definitely broken on ppc64).

The darwin/arm64 ones are more concerning. It looks like the stack barrier list is just wrong (e.g., [@@@ ==> *0xd=0x0] in the last one). That's a bad pointer and a bad value. The "missed stack barrier" panic is almost certainly just a symptom of the earlier nil-pointer dereference in gcRemoveStackBarrier, but I'm not sure where the bad barrier pointers came from in the first place.

Is this builder a multicore ARM64 or single core? If it's multicore, this could be a weak memory order issue.

I don't know the exact hardware on the builder, but the builder name (darwin-arm64-a7ios) suggests it is running on an Apple A7 processor. A7 has 2 cores according to https://en.wikipedia.org/wiki/Apple_A7.

I'm not aware of any single core arm64 implementations fwiw. There probably are some, but they're definitely not the common case.

TestStackBarrierProfiling just failed on android/arm with missed stack barrier:

https://build.golang.org/log/032ea3f75a48e9760600042046066e24a5e3234e

Here are some recent failures. Twice on android/arm64 (which may be expected)

https://build.golang.org/log/3f674668ee150f41b147bd038d54abc6540ebdf3
https://build.golang.org/log/9cc449cbedd4ae6cdf9d3377ba99201f383db611

But also one on linux/arm64:

https://build.golang.org/log/6c5f8cce8abb0fd0cb095820cedf2e7764d6c191

CL https://golang.org/cl/23134 mentions this issue.

CL https://golang.org/cl/23291 mentions this issue.

Here's a recent one from an android/arm64 builder:

https://build.golang.org/log/e7ef66722bdccf4446c52fbfbb8783883662c2b4

You mentioned that TestStackBarrierProfiling on android/arm64 might not work reliably for other reasons than this issue's topic. Should I open a new issue, and perhaps skip TestStackBarrierProfiling on android/arm64 (and perhaps other GOOS/GOARCH combinations) in the meantime?