runtime: TestLFStackStress fails on darwin/arm on Apple A7 chip

[crawshaw]

$ go test -cpu=2 -run=TestLFStackStress runtime
--- FAIL: TestLFStackStress-2 (0.58s)
lfstack_test.go:128: Wrong number of nodes 3/100
FAIL

There is also a -cpu=2 channel test failure (TestMultiConsumer), so to rule out the wait channel in the test I tried, rather crudely, swapping it out for a WaitGroup. With the WaitGroup it gives exactly the same error as above, which points in the direction of atomicload64 / cas64 inside the lfstack implementation.

[randall77]

@dvyukov

[crawshaw]

This test passes on an iPhone 4S (dual core Cortex-A9).
It fails on an iPad Mini 3 (dual core 64-bit Apple-A7).

Perhaps Apple broke some locking assumption when they implemented ARMv7 support on their ARMv8 chip.

This doesn't matter for iOS apps, as the App Store requires shipping darwin/arm64 binaries, and those are the binaries that will be used on those chips. For now I'll keep using the iPhone 4S as the darwin/arm builder.

[rsc]

Is this using the atomics in runtime/atomic_arm.go that are implemented with locks? It's a little hard to believe that locks are broken and this is the only thing that fails. But I don't see any non-lock version for 32-bit arm.

[dvyukov]

Mutexes use cas function in lock. On linux/arm we use kernel-provided cas implementation that contains memory barriers if necessary. On darwin/arm we use our own implementation that misses memory barriers. So mutexes can well be broken.

[crawshaw]

Several stdlib tests fail on this device, this was just the simplest of them.

[gopherbot]

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