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

cache_tests::stable_hash test fails on s390x #39

Closed
alexanderkjall opened this issue Jul 2, 2023 · 1 comment · Fixed by #49
Closed

cache_tests::stable_hash test fails on s390x #39

alexanderkjall opened this issue Jul 2, 2023 · 1 comment · Fixed by #49

Comments

@alexanderkjall
Copy link
Contributor

alexanderkjall commented Jul 2, 2023

Output:

---- cache_tests::stable_hash stdout ----
thread 'cache_tests::stable_hash' panicked at 'assertion failed: `(left == right)`
  left: `"038D651019410545"`,
 right: `"7D208C81E8236995"`', src/lib.rs:869:9
stack backtrace:
   0: rust_begin_unwind
             at /usr/src/rustc-1.63.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:142:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
             at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:181:5
   4: bkt::cache_tests::stable_hash
             at ./src/lib.rs:869:9
   5: bkt::cache_tests::stable_hash::{{closure}}
             at ./src/lib.rs:868:5
   6: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
   7: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

This looks like it might be a big/small endian problem.

Build log: https://ci.debian.net/data/autopkgtest/testing/s390x/r/rust-bkt/34502277/log.gz

@dimo414
Copy link
Owner

dimo414 commented Jul 8, 2023

Thanks for the report, this test is mostly just a change-detector so it's probably simplest to disable it for this architecture (unless the errors you're seeing are non-deterministic which would be a bigger problem). Would you like to send a PR to disable this test?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants