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

zvariant v3.14.0: test failures on 32-bit x86 (i686-unknown-linux-gnu) #357

Closed
decathorpe opened this issue May 23, 2023 · 7 comments · Fixed by #362
Closed

zvariant v3.14.0: test failures on 32-bit x86 (i686-unknown-linux-gnu) #357

decathorpe opened this issue May 23, 2023 · 7 comments · Fixed by #362
Labels
bug Something isn't working gvariant zvariant Issues/PRs related to zvariant crate

Comments

@decathorpe
Copy link
Contributor

With the most recent release, the dev-dependency on a git snapshot of the glib crate was replaced with a normal dependency, which allowed me to run test suite of zvariant during package builds for Fedora Linux - which in turn has surfaced a few test failures on 32-bit x86 (i.e. i686).

This is the output (truncated to only --lib results, doc-tests all passed) from cargo test --release (with a few more distro-specific flags which should not affect results):

running 37 tests
(...)
failures:
---- tests::dict_value stdout ----
[src/lib.rs:1027] encoded.len() = 40
thread 'tests::dict_value' panicked at 'no entry found for key', src/lib.rs:1047:24
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
---- tests::f64_value stdout ----
thread 'tests::f64_value' panicked at 'assertion failed: (decode_with_gvariant::<_, f64>(encoded) - -5.759340900185448e-128).abs() <\n    f64::EPSILON', src/lib.rs:391:13
---- tests::i32_value stdout ----
thread 'tests::i32_value' panicked at 'assertion failed: `(left == right)`
  left: `-180071088`,
 right: `1347765493`', src/lib.rs:364:13
---- tests::i16_value stdout ----
thread 'tests::i16_value' panicked at 'assertion failed: `(left == right)`
  left: `-2736`,
 right: `20725`', src/lib.rs:342:13
---- tests::i64_value stdout ----
thread 'tests::i64_value' panicked at 'assertion failed: `(left == right)`
  left: `-773399484024203952`,
 right: `5788608029063988469`', src/lib.rs:377:13
---- tests::option_value stdout ----
thread 'tests::option_value' panicked at 'assertion failed: `(left == right)`
  left: `Some(4096)`,
 right: `Some(16)`', src/lib.rs:1580:9
---- tests::u32_value stdout ----
thread 'tests::u32_value' panicked at 'assertion failed: `(left == right)`
  left: `2881137594`,
 right: `3131816619`', src/lib.rs:353:13
---- tests::u16_value stdout ----
thread 'tests::u16_value' panicked at 'assertion failed: `(left == right)`
  left: `43962`,
 right: `47787`', src/lib.rs:331:13
failures:
    tests::dict_value
    tests::f64_value
    tests::i16_value
    tests::i32_value
    tests::i64_value
    tests::option_value
    tests::u16_value
    tests::u32_value
test result: FAILED. 29 passed; 8 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

It's not easy to reproduce this on a x86_64 host system because you need a cross-compiler setup for 32-bit GLib, but I can try to provide reproducing steps that use containers / VMs of some sort if that helps.

@zeenix
Copy link
Contributor

zeenix commented May 23, 2023

@decathorpe Ooh interesting. Thanks so much for filing these. Obviously I never tested on 32-bit machines. 😆 I'll check it out..

@zeenix zeenix added bug Something isn't working zvariant Issues/PRs related to zvariant crate gvariant labels May 26, 2023
@zeenix
Copy link
Contributor

zeenix commented May 27, 2023

This is very strange. It seems the bytes are being read as big endian by glib, which uses the host endian. If this was just i686 machine, the native encoding should be little endian. 🤔

@zeenix
Copy link
Contributor

zeenix commented May 27, 2023

Ah, I know what happened. You mixed up the error message of this issue with #358. 😆

zeenix added a commit to zeenix/zbus that referenced this issue May 27, 2023
If the native pointer size is 32-bit, then the 64-bit offset support is
not needed.

This also fixes the assumption that when a 32-bit offset is bumped, we
end up with a 64-bit offset. This is not true on 32-bit systems because
we use `usize` for offsets, which is 32-bit on 32-bit systems.

Fixes dbus2#357.
@zeenix
Copy link
Contributor

zeenix commented May 27, 2023

Ah, I know what happened. You mixed up the error message of this issue with #358. laughing

Assuming this is the case, #362 should fix both the issues you filed. Please test and let me know. 🙏

@decathorpe
Copy link
Contributor Author

Oh, this is embarassing. You're indeed right. I had both logs open in browser tabs and pasted the wrong one into the issues. :( I'll test the PR, and report back.

@decathorpe
Copy link
Contributor Author

I can confirm that this PR fixes the failure I saw on i686.

@zeenix
Copy link
Contributor

zeenix commented May 28, 2023

It's ok. It happens. 😊

Thanks for testing! I wish there was an i686 runner available from GH.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working gvariant zvariant Issues/PRs related to zvariant crate
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants