-
Notifications
You must be signed in to change notification settings - Fork 76
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
Test failed on arm64 #34
Comments
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale looks like this went unnoticed, but i find the signed / unsigned diff quite odd, if that is comparing amd64 and arm64. we don't have CI signal for arm64 but it is claimed as a supported platform, so PRs to fix this bug are welcome. |
@neolit123: Please ensure the request meets the requirements listed here. If this request no longer meets these requirements, the label can be removed In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
I'm having a similar issue on aarch64, s390x and ppc64: https://koji.fedoraproject.org/koji/taskinfo?taskID=45709245 |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@fejta-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/reopen EDIT: looks like more platforms have the problem:
|
@neolit123: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@neolit123 : there is something really funky going on in the FPU or math libs on arm64: package main
import "fmt"
import "math"
func main() {
x := float64(9223372036854775808.0)
fmt.Printf("f %f\n", float64(x))
fmt.Printf("b %b\n", math.Float64bits(x))
fmt.Printf("i %d\n", int64(x))
fmt.Printf("u %d\n", uint64(x))
y := math.Pow(2,63)
fmt.Printf("f %f\n", float64(y))
fmt.Printf("b %b\n", math.Float64bits(y))
fmt.Printf("i %d\n", int64(y))
fmt.Printf("u %d\n", uint64(y))
} Even though the floating point number is binary indentical, it still produces different results ?!?
|
this is not right. (EDIT: after some digging, more in the lines of "potential behavior") can you please:
and share the output here. i doubt this is hardware related (e.g. VFP) and seems more like a compiler bug.
we might have to report this to golang. |
just ran the same code with:
in:
using:
and got:
which now has the int64() cast print MAX_INT64 for both cases.
it appears to be pining the literal of MAX_INT64 (9223372036854775807) in the first case and fetching it from the stack for the second case. i think this is just a matter of optimization and the fact that 9223372036854775808 overflows int64 can make the compiler make volatile choices. similar can be observed with GCC. so unit testing around maximums and trying to get consistent results from optimizing compilers in a cross platform way is not something that will work very well for us here. http://c0x.coding-guidelines.com/6.3.1.4.html
cc @sttts |
I used go 1.15.2 running on amd64 (with GOARCH=arm64), and aarch64 qemu to run it (I suppose) Re-running the same test on a Raspberry Pi 4, I also get 9223372036854775807 for both of them... |
Not sure what happens recently, it seems the issue is gone on real HW. See the log at https://ci.debian.net/packages/g/golang-k8s-sigs-yaml/testing/arm64/ starting from 2020-03-08, the test is green.. the log is rotated, so no idea what changes.. |
It was indeed the optimizer, that caused it to behave differently the first time.
|
the test fails consistently on RPi4 (A72) https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/README.md ubuntu@ubuntu:~/kubernetes-yaml$ grep PRETTY /etc/os-release PRETTY_NAME="Ubuntu 20.04.1 LTS" ubuntu@ubuntu:~/kubernetes-yaml$ uname -m -r 5.4.0-1022-raspi aarch64 ubuntu@ubuntu:~/kubernetes-yaml$ go test -v ./ -run TestJSONObjectToYAMLObject === RUN TestJSONObjectToYAMLObject === RUN TestJSONObjectToYAMLObject/nil === RUN TestJSONObjectToYAMLObject/empty === RUN TestJSONObjectToYAMLObject/values yaml_test.go:489: jsonToYAML() = (yaml.MapSlice) (len=15 cap=15) { (yaml.MapItem) { Key: (string) (len=4) "bool", Value: (bool) true }, (yaml.MapItem) { Key: (string) (len=9) "empty map", Value: (yaml.MapSlice) }, (yaml.MapItem) { Key: (string) (len=11) "empty slice", Value: ([]interface {}) { } }, (yaml.MapItem) { Key: (string) (len=7) "float64", Value: (float64) 42.1 }, (yaml.MapItem) { Key: (string) (len=12) "fractionless", Value: (int) 42 }, (yaml.MapItem) { Key: (string) (len=3) "int", Value: (int) 42 }, (yaml.MapItem) { Key: (string) (len=5) "int64", Value: (int) 42 }, (yaml.MapItem) { Key: (string) (len=9) "int64 big", Value: (int) 4611686018427387904 }, (yaml.MapItem) { Key: (string) (len=3) "map", Value: (yaml.MapSlice) (len=1 cap=1) { (yaml.MapItem) { Key: (string) (len=3) "foo", Value: (string) (len=3) "bar" } } }, (yaml.MapItem) { Key: (string) (len=18) "negative int64 big", Value: (int) -4611686018427387904 }, (yaml.MapItem) { Key: (string) (len=7) "nil map", Value: (interface {}) }, (yaml.MapItem) { Key: (string) (len=9) "nil slice", Value: (interface {}) }, (yaml.MapItem) { Key: (string) (len=5) "slice", Value: ([]interface {}) (len=2 cap=2) { (string) (len=3) "foo", (string) (len=3) "bar" } }, (yaml.MapItem) { Key: (string) (len=6) "string", Value: (string) (len=3) "foo" }, (yaml.MapItem) { Key: (string) (len=10) "uint64 big", Value: (int) 9223372036854775807 } } , want (yaml.MapSlice) (len=15 cap=15) { (yaml.MapItem) { Key: (string) (len=4) "bool", Value: (bool) true }, (yaml.MapItem) { Key: (string) (len=9) "empty map", Value: (yaml.MapSlice) }, (yaml.MapItem) { Key: (string) (len=11) "empty slice", Value: ([]interface {}) { } }, (yaml.MapItem) { Key: (string) (len=7) "float64", Value: (float64) 42.1 }, (yaml.MapItem) { Key: (string) (len=12) "fractionless", Value: (int) 42 }, (yaml.MapItem) { Key: (string) (len=3) "int", Value: (int) 42 }, (yaml.MapItem) { Key: (string) (len=5) "int64", Value: (int) 42 }, (yaml.MapItem) { Key: (string) (len=9) "int64 big", Value: (int) 4611686018427387904 }, (yaml.MapItem) { Key: (string) (len=3) "map", Value: (yaml.MapSlice) (len=1 cap=1) { (yaml.MapItem) { Key: (string) (len=3) "foo", Value: (string) (len=3) "bar" } } }, (yaml.MapItem) { Key: (string) (len=18) "negative int64 big", Value: (int) -4611686018427387904 }, (yaml.MapItem) { Key: (string) (len=7) "nil map", Value: (interface {}) }, (yaml.MapItem) { Key: (string) (len=9) "nil slice", Value: (interface {}) }, (yaml.MapItem) { Key: (string) (len=5) "slice", Value: ([]interface {}) (len=2 cap=2) { (string) (len=3) "foo", (string) (len=3) "bar" } }, (yaml.MapItem) { Key: (string) (len=6) "string", Value: (string) (len=3) "foo" }, (yaml.MapItem) { Key: (string) (len=10) "uint64 big", Value: (uint64) 9223372036854775808 } } yaml_test.go:528: yaml.Unmarshal(json.Marshal(tt.input)) = (yaml.MapSlice) (len=15 cap=16) { (yaml.MapItem) { Key: (string) (len=4) "bool", Value: (bool) true }, (yaml.MapItem) { Key: (string) (len=9) "empty map", Value: (yaml.MapSlice) }, (yaml.MapItem) { Key: (string) (len=11) "empty slice", Value: ([]interface {}) { } }, (yaml.MapItem) { Key: (string) (len=7) "float64", Value: (float64) 42.1 }, (yaml.MapItem) { Key: (string) (len=12) "fractionless", Value: (int) 42 }, (yaml.MapItem) { Key: (string) (len=3) "int", Value: (int) 42 }, (yaml.MapItem) { Key: (string) (len=5) "int64", Value: (int) 42 }, (yaml.MapItem) { Key: (string) (len=9) "int64 big", Value: (int) 4611686018427388000 }, (yaml.MapItem) { Key: (string) (len=3) "map", Value: (yaml.MapSlice) (len=1 cap=1) { (yaml.MapItem) { Key: (string) (len=3) "foo", Value: (string) (len=3) "bar" } } }, (yaml.MapItem) { Key: (string) (len=18) "negative int64 big", Value: (int) -4611686018427388000 }, (yaml.MapItem) { Key: (string) (len=7) "nil map", Value: (interface {}) }, (yaml.MapItem) { Key: (string) (len=9) "nil slice", Value: (interface {}) }, (yaml.MapItem) { Key: (string) (len=5) "slice", Value: ([]interface {}) (len=2 cap=2) { (string) (len=3) "foo", (string) (len=3) "bar" } }, (yaml.MapItem) { Key: (string) (len=6) "string", Value: (string) (len=3) "foo" }, (yaml.MapItem) { Key: (string) (len=10) "uint64 big", Value: (uint64) 9223372036854776000 } } , want (yaml.MapSlice) (len=15 cap=15) { (yaml.MapItem) { Key: (string) (len=4) "bool", Value: (bool) true }, (yaml.MapItem) { Key: (string) (len=9) "empty map", Value: (yaml.MapSlice) }, (yaml.MapItem) { Key: (string) (len=11) "empty slice", Value: ([]interface {}) { } }, (yaml.MapItem) { Key: (string) (len=7) "float64", Value: (float64) 42.1 }, (yaml.MapItem) { Key: (string) (len=12) "fractionless", Value: (int) 42 }, (yaml.MapItem) { Key: (string) (len=3) "int", Value: (int) 42 }, (yaml.MapItem) { Key: (string) (len=5) "int64", Value: (int) 42 }, (yaml.MapItem) { Key: (string) (len=9) "int64 big", Value: (int) 4611686018427388000 }, (yaml.MapItem) { Key: (string) (len=3) "map", Value: (yaml.MapSlice) (len=1 cap=1) { (yaml.MapItem) { Key: (string) (len=3) "foo", Value: (string) (len=3) "bar" } } }, (yaml.MapItem) { Key: (string) (len=18) "negative int64 big", Value: (int) -4611686018427388000 }, (yaml.MapItem) { Key: (string) (len=7) "nil map", Value: (interface {}) }, (yaml.MapItem) { Key: (string) (len=9) "nil slice", Value: (interface {}) }, (yaml.MapItem) { Key: (string) (len=5) "slice", Value: ([]interface {}) (len=2 cap=2) { (string) (len=3) "foo", (string) (len=3) "bar" } }, (yaml.MapItem) { Key: (string) (len=6) "string", Value: (string) (len=3) "foo" }, (yaml.MapItem) { Key: (string) (len=10) "uint64 big", Value: (int) -9223372036854775000 } } |
@zhsj : the "green" tests on debian are probably related to this patch: :-P |
hmm, sorry I forget I disabled that... it happens so long ago.. 🤦 |
does this patch work for you @zhsj @afbjorklund ? diff --git a/yaml_test.go b/yaml_test.go
index a88cbf3..f28cb8f 100644
--- a/yaml_test.go
+++ b/yaml_test.go
@@ -459,7 +459,7 @@ func TestJSONObjectToYAMLObject(t *testing.T) {
"map": map[string]interface{}{"foo": "bar"},
"slice": []interface{}{"foo", "bar"},
"string": string("foo"),
- "uint64 big": float64(math.Pow(2, 63)),
+ "uint64 big": uint64(9223372036854776000),
},
expected: yaml.MapSlice{
{Key: "nil slice"},
@@ -476,7 +476,7 @@ func TestJSONObjectToYAMLObject(t *testing.T) {
{Key: "map", Value: yaml.MapSlice{{Key: "foo", Value: "bar"}}},
{Key: "slice", Value: []interface{}{"foo", "bar"}},
{Key: "string", Value: string("foo")},
- {Key: "uint64 big", Value: uint64(1) << 63},
+ {Key: "uint64 big", Value: uint64(9223372036854776000)},
},
},
} |
@neolit123 : it works OK with qemu, don't have the RPi4 here atm GOARCH=arm64 go test -v ./ -run TestJSONObjectToYAMLObject
=== RUN TestJSONObjectToYAMLObject
=== RUN TestJSONObjectToYAMLObject/nil
=== RUN TestJSONObjectToYAMLObject/empty
=== RUN TestJSONObjectToYAMLObject/values
--- PASS: TestJSONObjectToYAMLObject (0.04s)
--- PASS: TestJSONObjectToYAMLObject/nil (0.01s)
--- PASS: TestJSONObjectToYAMLObject/empty (0.00s)
--- PASS: TestJSONObjectToYAMLObject/values (0.02s)
PASS
ok sigs.k8s.io/yaml 0.128s |
@neolit123 maybe would help to add an ARM64 job for Travis. |
yes, looks like someone tried to add ppc64le here: |
may be a bit simpler for ARM64 :) |
Maybe add ARM32 ( It had another one of those long-standing trivial bugs (#23) |
SGTM, the supported platforms are here: |
Funny, the Graviton2 tests pass: https://travis-ci.org/github/kubernetes-sigs/yaml/builds/743332132. @afbjorklund I don't see ARM32 support in TravisCI: https://docs.travis-ci.com/user/multi-cpu-architectures/#multi-cpu-availaibility. |
It seems travis is booting an amd64 vm when it should be arm64-graviton2 https://travis-ci.org/github/kubernetes-sigs/yaml/jobs/743332141#L189
|
oh, travis says 'arm64-graviton2 available only on travis-ci.com' |
Maybe it supports That's how I prefer to run it myself...
So that I can test arm32/arm64 from laptop. |
It should be ok to run arm32 on arm64 env. Just tell Go with GOARCH=arm. |
Or run it all from the same VM, perhaps ?
Hardware emulation only when needed... Too bad that Travis gave up on containers :-( |
At least they could have failed the test... 😞
Will update the PR soon. |
Seems ominous... Same as Docker Hub, perhaps ? Then again:
|
Problem will be migrating. Not sure how would be done for the k8s repos and if Prow will be able to see job status. |
Minikube just stopped using Travis and moved to GitHub Actions instead. There's still some Jenkins around though. |
The problem with GH actions is that there is no ARM support (yet). Other than that, it's a good call, considering that TravisCI rate limited the open source jobs. |
You can use external workers for that, in the meantime (or QEMU) |
If I would do it for my company, external workers would be an option, but not here. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@fejta-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/remove-lifecycle rotten |
/reopen |
@hakman: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
The diff is
and
The text was updated successfully, but these errors were encountered: