Test failure in `runtime::tests::queue::stress1`

[Darksonn]

Version

The test happened in CI on PR #7249 which is based on commit c3037ad. The changes in the PR do not seem related.

Platform

The failure occurred in the FreeBSD 64-bit job.

Description

The following crash was observed in a CI test:

test sync::tests::atomic_waker::basic_usage ... ok
test sync::tests::atomic_waker::wake_without_register ... ok
test sync::tests::notify::notify_clones_waker_before_lock ... ok
test sync::tests::notify::notify_simple ... ok
test sync::tests::notify::notify_waiters_handles_panicking_waker ... ok
test sync::tests::notify::watch_test ... ok
test sync::tests::semaphore_batch::cancel_acquire_releases_permits ... ok
test sync::tests::semaphore_batch::close_semaphore_notifies_permit1 ... ok
test sync::tests::semaphore_batch::close_semaphore_notifies_permit2 ... ok
test sync::tests::semaphore_batch::close_semaphore_prevents_acquire ... ok
test sync::tests::semaphore_batch::forget_permits_basic ... ok
test sync::tests::semaphore_batch::max_permits_doesnt_panic ... ok
test sync::tests::semaphore_batch::poll_acquire_many_available ... ok
test sync::tests::semaphore_batch::poll_acquire_many_unavailable ... ok
test sync::tests::semaphore_batch::poll_acquire_one_available ... ok
test sync::tests::semaphore_batch::poll_acquire_one_unavailable ... ok
test sync::tests::semaphore_batch::poll_acquire_one_zero_permits ... ok
test sync::tests::semaphore_batch::release_permits_at_drop ... ok
test sync::tests::semaphore_batch::try_acquire_many_available ... ok
test sync::tests::semaphore_batch::try_acquire_many_unavailable ... ok
test sync::tests::semaphore_batch::try_acquire_one_available ... ok
test sync::tests::semaphore_batch::try_acquire_one_unavailable ... ok
test sync::tests::semaphore_batch::update_permits_many_times ... ok
test sync::tests::semaphore_batch::validates_max_permits - should panic ... ok
test task::coop::test::budgeting ... ok
test task::local::tests::local_current_thread_scheduler ... ok
test task::local::tests::wakes_to_local_queue ... ok
test util::idle_notified_set::tests::join_set_test ... ok
test util::linked_list::tests::const_new ... ok
test util::linked_list::tests::push_and_drain ... ok
test util::linked_list::tests::push_pop_push_pop ... ok
test util::linked_list::tests::remove_by_address ... ok
test util::memchr::tests::memchr_all ... ok
test util::memchr::tests::memchr_empty ... ok
test util::memchr::tests::memchr_test ... ok
test runtime::tests::task_combinations::test_combinations ... ok

failures:

---- runtime::tests::queue::stress1 stdout ----

thread 'runtime::tests::queue::stress1' panicked at tokio/src/runtime/tests/queue.rs:214:9:
assertion `left == right` failed
  left: 499997
 right: 500000
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    runtime::tests::queue::stress1

test result: FAILED. 131 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.27s

error: test failed, to rerun pass `-p tokio --lib`

Exit status: 101

See the cirrus ci run for more info.

This is the failed assertion:

tokio/tokio/src/runtime/tests/queue.rs

Line 214 in c3037ad

assert_eq!(n, NUM_LOCAL * NUM_PUSH);

[PaulDance]

The following run succeeded while no change was introduced since the failure.

[Darksonn]

Yes, as I suspected this is a spurious failure. It means that it's an error that only happens rarely.