rusty_pool icon indicating copy to clipboard operation
rusty_pool copied to clipboard

fails 2 tests on 32bit archs

Open jonassmedegaard opened this issue 3 years ago • 1 comments

I have packaged rusty_pool for Debian, but experience the testsuite failing for the architectures armv5te armv7 i686 mipsel - basically all of the 32bit architectures supported by Debian (overview of build logs here).

Below are details for armv5te (the other build failures look similar from a quick look):

---- tests::test_try_increment_worker_total stdout ----
thread 'tests::test_try_increment_worker_total' panicked at 'assertion failed: `(left == right)`
  left: `65536`,
 right: `0`', src/lib.rs:1802:9
stack backtrace:
   0: rust_begin_unwind
             at /usr/src/rustc-1.61.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /usr/src/rustc-1.61.0/library/core/src/panicking.rs:143:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
             at /usr/src/rustc-1.61.0/library/core/src/panicking.rs:182:5
   4: rusty_pool::tests::test_try_increment_worker_total
   5: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.61.0/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

---- tests::worker_count_test stdout ----
thread 'tests::worker_count_test' panicked at 'assertion failed: `(left == right)`
  left: `63581`,
 right: `456797`', src/lib.rs:1766:9
stack backtrace:
   0: rust_begin_unwind
             at /usr/src/rustc-1.61.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /usr/src/rustc-1.61.0/library/core/src/panicking.rs:143:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
             at /usr/src/rustc-1.61.0/library/core/src/panicking.rs:182:5
   4: rusty_pool::tests::worker_count_test
   5: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.61.0/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Please tell if I can do more to help shed light on this - e.g. if helpful that I rebuild with "BACKTRACE=full".

jonassmedegaard avatar Oct 27 '22 14:10 jonassmedegaard

The pool uses one AtomicUsize to store both the number of idle threads and total threads, on 32 bit platforms that means 16 bit each.

For test_try_increment_worker_total the problem is right here: assert_eq!(witness, 0x0000_0001_0000_0000); This was probably simply forgotten when moving from AtomicU64 to AtomicUsize and should be changed to something like 1 << (std::mem::size_of::<usize>() * 8 / 2) to work on all platforms.

The test worker_count_test simply overflows on 32 bit because it reaches numbers above 2^16 - 1. Luckily this isn't actually a problem in the pool because the builder validates the upper bounds of the max pool size. The test should either just use lower numbers or check something like #[cfg(target_pointer_width = "32")].

robinfriedli avatar Oct 31 '22 11:10 robinfriedli