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

[bug] test failure on 32-bit arches #282

Open
werdahias opened this issue Sep 23, 2024 · 3 comments
Open

[bug] test failure on 32-bit arches #282

werdahias opened this issue Sep 23, 2024 · 3 comments

Comments

@werdahias
Copy link

heed was packaged for Debian; its testsuite fails on 32-bit arches:

470s running 20 tests
470s test env::tests::open_already_existing_database ... ok
470s test env::tests::open_database_with_writemap_flag ... ok
470s test env::tests::create_database_without_commit ... ok
470s test mdb::lmdb_error::test::test_description ... ok
470s test iterator::tests::rev_range_iter_last ... ok
470s test tests::error_is_send_sync ... ok
470s test env::tests::open_env_with_named_path ... ok
470s test iterator::tests::range_iter_last_with_byte_255 ... ok
470s test iterator::tests::iter_last ... ok
470s test env::tests::open_database_with_nosubdir ... ok
470s test env::tests::resize_database ... ok
470s test iterator::tests::rev_prefix_iter_last ... ok
470s test iterator::tests::prefix_iter_last_with_byte_255 ... ok
470s test iterator::tests::range_iter_last ... ok
470s test iterator::tests::rev_prefix_iter_last_with_byte_255 ... ok
470s test iterator::tests::prefix_iter_last ... ok
470s test env::tests::reopen_env_with_different_options_is_err ... ok
470s test iterator::tests::rev_range_iter_last_with_byte_255 ... ok
470s test env::tests::open_read_only_without_no_env_opened_before ... FAILED
471s test env::tests::close_env ... ok
471s 
471s failures:
471s 
471s ---- env::tests::open_read_only_without_no_env_opened_before stdout ----
471s thread 'env::tests::open_read_only_without_no_env_opened_before' panicked at src/env.rs:1030:27:
471s attempt to multiply with overflow
471s stack backtrace:
471s    0: rust_begin_unwind
471s              at /usr/src/rustc-1.80.1/library/std/src/panicking.rs:652:5
471s    1: core::panicking::panic_fmt
471s              at /usr/src/rustc-1.80.1/library/core/src/panicking.rs:72:14
471s    2: core::panicking::panic_const::panic_const_mul_overflow
471s              at /usr/src/rustc-1.80.1/library/core/src/panicking.rs:179:21
471s    3: heed::env::tests::open_read_only_without_no_env_opened_before
471s              at ./src/env.rs:1030:27
471s    4: heed::env::tests::open_read_only_without_no_env_opened_before::{{closure}}
471s              at ./src/env.rs:1023:53
471s    5: core::ops::function::FnOnce::call_once
471s              at /usr/src/rustc-1.80.1/library/core/src/ops/function.rs:250:5
471s    6: core::ops::function::FnOnce::call_once
471s              at /usr/src/rustc-1.80.1/library/core/src/ops/function.rs:250:5
471s note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
471s 
471s 
471s failures:
471s     env::tests::open_read_only_without_no_env_opened_before
471s 
471s test result: FAILED. 19 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.01s

Looks like this test exceeds the limit on those arches causing it to overflow.

@a-wai
Copy link

a-wai commented Oct 11, 2024

I just noticed a mismatch between the comment and actual code on the crashing line: the comment says "10MB", but the actual value is 16GB; if the comment is right, reflecting it in the code would solve this issue as 10M doesn't overflow on 32-bit systems.

@Kerollmops
Copy link
Member

Hey @a-wai 👋

Thank you for the report. I wonder if it is possible on the GitHub CI to run stuff on a 32-bit platform or at least run them like they are running on a 32-bit platform. Would you mind doing a PR to either fix the value to put less than 4GiB (instead of 16GiB) and/or adding a CI pass to run the tests as 32-bit, please?

Have a nice one 🌻

@a-wai
Copy link

a-wai commented Nov 25, 2024

Hi @Kerollmops !

I'm not familiar with GitHub CI, so I doubt I can do anything here; the idea being basically to execute the job(s) in a 32-bit container (such as i386/debian), which will therefore behave like a 32-bit machine, even when running on a 64-bit host.

I'll come up with a patch for the code part of it asap anyway.

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

No branches or pull requests

3 participants