Unit test failure in 'tests::blns'

[luke-titley]

Hey, I'm getting a unit test failure in tests::blns. I'm on a mac (mojave 10.14.10).

This is on the master and serde branches.

Release and debug builds.

running 6 tests
test hash::test_hashing ... ok
test tests::c_str_works ... ok
test tests::it_works ... ok
test tests::empty_string ... ok
test tests::blns ... FAILED
test tests::raft ... ok

failures:

---- tests::blns stdout ----
thread 'tests::blns' panicked at 'assertion failed: `(left == right)`
  left: `0`,
 right: `1315`', src/lib.rs:467:9
stack backtrace:
   0: std::panicking::default_hook::{{closure}}
   1: std::panicking::default_hook
   2: std::panicking::rust_panic_with_hook
   3: std::panicking::continue_panic_fmt
   4: std::panicking::begin_panic_fmt
   5: ustr::tests::blns
   6: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
   7: __rust_maybe_catch_panic
   8: test::run_test::run_test_inner::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[luke-titley]

 // check that the number of entries is the same
assert_eq!(super::num_entries(), hs.len());

[anderslanglands]

Did you run it with

RUST_TEST_THREADS=1 cargo test

?

On Sat, 9 Nov 2019 at 11:35, luke-titley notifications@github.com wrote:

// check that the number of entries is the same assert_eq!(super::num_entries(), hs.len());

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/anderslanglands/ustr/issues/4?email_source=notifications&email_token=AAOYQXPBL5OSWU4WY6SLQYDQSXSURA5CNFSM4JK7ZGSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDTR3CY#issuecomment-552017291, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOYQXM6T6W6K7MX2HKJYGTQSXSURANCNFSM4JK7ZGSA .

[luke-titley]

Everything passes when it's all on one thread.

[anderslanglands]

Great!

On Sun, 10 Nov 2019 at 04:33, luke-titley notifications@github.com wrote:

Everything passes when it's all on one thread.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/anderslanglands/ustr/issues/4?email_source=notifications&email_token=AAOYQXPI3ENGP25O5ZLKTG3QS3J5ZA5CNFSM4JK7ZGSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDUIUXQ#issuecomment-552110686, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOYQXPNOETYLBX4DAT2LWLQS3J5ZANCNFSM4JK7ZGSA .

[luke-titley]

Is it intended to be thread safe ?

[anderslanglands]

Yes, and it is.

What's happening is that some of the tests put, say, 5 strings in the cache, then check that there actually are 5 strings in the cache. This is fine when you run the tests on a single thread, but if multiple tests are running concurrently, then when the check happens there could be any number of strings in the cache because other tests are adding strings at the same time. This is to be expected and is still thread-safe, it's just not great for unit testing.

On Mon, 11 Nov 2019 at 10:58, luke-titley notifications@github.com wrote:

Is it intended to be thread safe ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/anderslanglands/ustr/issues/4?email_source=notifications&email_token=AAOYQXOBJFRZHOOSNMYKZR3QTB7W5A5CNFSM4JK7ZGSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDVIASI#issuecomment-552239177, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOYQXOVFHMJ6LZ6X54U3PLQTB7W5ANCNFSM4JK7ZGSA .

[luke-titley]

Aaah, right. Great!

[luke-titley]

Ah, I'm a fool. You already wrote this in the README.md

[anderslanglands]

No worries :)