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

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

Closed
crawshaw opened this issue Mar 18, 2015 · 6 comments
Closed

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

crawshaw opened this issue Mar 18, 2015 · 6 comments
Milestone

Comments

@crawshaw
Copy link
Member

$ 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
Copy link
Contributor

@dvyukov

@crawshaw
Copy link
Member Author

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
Copy link
Contributor

rsc commented Apr 10, 2015

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.

@rsc rsc changed the title runtime: darwin/arm lfstack test failure runtime: TestLFStackStress fails on darwin/arm on Apple A7 chip Apr 10, 2015
@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@dvyukov
Copy link
Member

dvyukov commented Apr 10, 2015

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
Copy link
Member Author

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

@gopherbot
Copy link

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

@rsc rsc closed this as completed in 4bd8040 Jul 30, 2015
@mikioh mikioh modified the milestones: Go1.5, Unplanned Jul 31, 2015
@golang golang locked and limited conversation to collaborators Aug 5, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants