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

new test failure on s390x (big-endian / IBM System Z) in image v0.24.8 compared to v0.24.7 #2098

Closed
decathorpe opened this issue Jan 13, 2024 · 2 comments · Fixed by #2099
Closed

Comments

@decathorpe
Copy link

I'm responsible for building the packages for the image crate for Fedora Linux, and I noticed a test failure that is new in image v0.24.8.

The failing test is check_references from the tests/reference_images.rs file:

failures:
---- check_references stdout ----
check_references tests/reference/tga/testsuite/cbw8.tga.3f8a9b3c.png
check_references tests/reference/tga/testsuite/ctc24.tga.b7096b3.png
check_references tests/reference/tga/testsuite/ubw8.tga.3f8a9b3c.png
check_references tests/reference/tga/testsuite/utc24.tga.b7096b3.png
check_references tests/reference/tga/testsuite/utc32.tga.134a83ba.png
check_references tests/reference/tiff/testsuite/hpredict.tiff.dc00a927.png
check_references tests/reference/tiff/testsuite/hpredict_packbits.tiff.82ca6aa0.png
check_references tests/reference/tiff/testsuite/mandrill.tiff.99549da9.png
check_references tests/reference/tiff/testsuite/rgb-3c-16b.tiff.531c087a.png
thread 'check_references' panicked at tests/reference_images.rs:278:13:
The decoded image's hash does not match (expected = 531c087a, actual = a7d24c79).
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
    check_references

s390x is the only big-endian architecture we support, so I suspect this as a likely cause of the issue. This test passes on all other architectures we support (x86_64, i686, aarch64, powerpc64le).

The parse_crc function in the same file looks suspiciously like it would not work as expected on architectures with big-endian byte order ... but its code has not changed since v0.24.7, so I'm not sure if this is the cause.

Test environment:

  • Fedora Rawhide
  • Rust 1.75.0
  • on s390x-unknown-linux-gnu
@fintelia
Copy link
Contributor

Thanks for reporting this! We're supposed to have CI validating that our tests pass on a big endian system. Unfortunately, it seems the overall CI runs have been showing as green despite the specific big endian checks not actually passing...

@decathorpe
Copy link
Author

Thank you for the quick fix!

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