Fedora - 'test_avoid_beacon seek_peers 2' panicked

[rossmuir]

Fedora release 20 (Heisenbug) / rustc 1.4.0-nightly (7e13faee1 2015-08-19)
2 cores and 2 gb memory

Tests hanging with error

test beacon::test::test_avoid_beacon ... thread 'test_avoid_beacon seek_peers 2' panicked at 'index out of bounds: the len is 0 but the index is 0', ../src/libcollections/vec.rs:1047

Whoever picks this one up I have created a Fedora CI to replicate and test this on - access on request.

[philiprhoades]

Happy to test or try anything but this seems to need a serious Rust programmer?

P.

[rossmuir]

Thanks and agreed it should be picked up by one of the team. We review issues weekly so, it may not be immediately addressed.

[vinipsmaker]

Can you provide the trace?

Maybe by setting the env RUST_BACKTRACE=1?

[rossmuir]

[jenkins@CI-Fedora crust]$ RUST_BACKTRACE=1 RUST_TEST_THREADS=1 cargo test
     Running target/debug/crust-cbd6f15be96df7f7

running 20 tests
test beacon::test::test_avoid_beacon ... thread 'test_avoid_beacon seek_peers 2' panicked at 'index out of bounds: the len is 0 but the index is 0', ../src/libcollections/vec.rs:1047
stack backtrace:
   1:     0x7fa265630119 - sys::backtrace::write::h4fa1c73e75dfa76bnbs
   2:     0x7fa2656338bc - panicking::on_panic::h4dd17a1f032345fc7bx
   3:     0x7fa2656208be - rt::unwind::begin_unwind_inner::h4a994192c9e1a672LEw
   4:     0x7fa265621367 - rt::unwind::begin_unwind_fmt::h8b4c2b5dd3ee277bRDw
   5:     0x7fa2656332f1 - rust_begin_unwind
   6:     0x7fa265661f2f - panicking::panic_fmt::h5f7bc89141895138x6E
   7:     0x7fa26565ed62 - panicking::panic_bounds_check::h07fc2c14e36aee06D5E
   8:     0x7fa26531491f - vec::Vec<T>.Index<usize>::index::h13299050826407003982
                        at ../src/libcollections/vec.rs:1047
   9:     0x7fa265316cde - beacon::test::test_avoid_beacon::closure.16920
                        at src/beacon.rs:316
  10:     0x7fa265316c03 - boxed::F.FnBox<A>::call_box::h5735186503288557655
                        at ../src/liballoc/boxed.rs:492
  11:     0x7fa265311e1b - boxed::Box<FnBox<A, Output $u3d$$u20$R$GT$$u2b$$u20$Send$u20$$u2b$$u20$$u27$a$GT$.FnOnce$LT$A$GT$::call_once::h2579762139354198355
                        at ../src/liballoc/boxed.rs:508
  12:     0x7fa265311a1d - thread::Builder::spawn_inner::closure.16741
                        at ../src/libstd/thread/mod.rs:279
  13:     0x7fa2653119c9 - rt::unwind::try::try_fn::h15155405352968911768
                        at ../src/libstd/rt/unwind/mod.rs:164
  14:     0x7fa265633298 - __rust_try
  15:     0x7fa26562dfb2 - rt::unwind::try::inner_try::hf68fe86557d86e71EAw
  16:     0x7fa265311933 - rt::unwind::try::h8620920136658640346
                        at ../src/libstd/rt/unwind/mod.rs:136
  17:     0x7fa2653117c8 - thread::Builder::spawn_inner::closure.16738
                        at ../src/libstd/thread/mod.rs:279
  18:     0x7fa26531201c - boxed::F.FnBox<A>::call_box::h11548694284578889021
                        at ../src/liballoc/boxed.rs:492
  19:     0x7fa265632723 - sys::thread::Thread::new::thread_start::hcb6e22587435a71drKv
  20:     0x7fa264389ee4 - start_thread
  21:     0x7fa264b9eb8c - clone
  22:                0x0 - <unknown>

Cheers @vinipsmaker

[Ghaunt]

I just do the test multiple times on VirtualBox with Fedora 22. 19 pass, 0 failed and 1 ignored. No panicked.

[philiprhoades]

OK, since Ghaunt didn't get the problem, I went ahead anyway and did the kvm VM machine test as well using:

Fedora-Live-Xfce-x86_64-22-3.iso

(which is what I used to create my two working machines with) and I still get the same error.

Ghaunt, which iso did you use to create your VM?

P.

[Ghaunt]

Fedora-Live-Workstation-x86_64-22-3.iso
I'll try to find your and try it again on a VM.

[Ghaunt]

I confirm too on this Fedora: Fedora-Live-Xfce-x86_64-22-3.iso
I got the same error.

It may be a Fedora issue on itself for that image. It's a pain in the ass to work with it. First I try on live CD and it's really buggy, don't want to boot, freeze, no longer responding to command. After installing it it was still slow and freeze temporarily some time.

[philiprhoades]

I don't have any of those booting problems - it works fine for me. I just have this Rust / crust problem . . which doesn't really make any sense to me - why should a preference for a particular desktop environment affect the testing of crust? - I tried it again outside of X but no improvement . .

[philiprhoades]

People,

I just ran the test from clone again with the same result:

Compiling crust v0.2.5 (file:///home/phil/src/rust/maidsafe/crust)
Running target/debug/crust-5a55922afd6d30b1

running 23 tests
test beacon::test::test_avoid_beacon ... thread 'test_avoid_beacon seek_peers 2' panicked at 'index out of bounds: the len is 0 but the index is 0', ../src/libcollections/vec.rs

but then I immediately did:

cargo clean ; cargo update ; cargo build ; cargo test

ie WITHOUT the prepended:

RUST_TEST_THREADS=1

and I get results:

Compiling crust v0.2.5 (file:///home/phil/src/rust/maidsafe/crust)
Running target/debug/crust-5a55922afd6d30b1

running 23 tests
test bootstrap_handler::test::serialisation ... ok
test config_utils::test::read_config_file_test ... FAILED
test connection_manager::test::bootstrap_off_list_connects ... ok
test bootstrap_handler::test::duplicates ... FAILED
test bootstrap_handler::test::oldest ... FAILED
test bootstrap_handler::test::prune ... FAILED
test connection_manager::test::network ... ignored
test getifaddrs::test::test_filter_loopback ... ok
test getifaddrs::test::test_getifaddrs ... ok
test bootstrap_handler::test::max_contacts ... FAILED
test tcp_connections::test::test_small_stream ... ok
test test::check_rust_unit_testing_is_not_parallel ... FAILED
test transport::test::test_ord ... ok
thread 'test_beacon receiver' panicked at 'index out of bounds: the len is 0 but the index is 0', ../src/libcollections/vec.rs:1047
test tcp_connections::test::test_multiple_nodes_small_stream ... ok
test utp_connections::test::establishing_connection ... ok
test connection_manager::test::bootstrap_off_list_connects_multiple ... ok
thread 'test_avoid_beacon seek_peers 2' panicked at 'index out of bounds: the len is 0 but the index is 0', ../src/libcollections/vec.rs:1047
test utp_connections::test::send_receive_data ... ok
test connection_manager::test::connection_manager ... ok
test connection_manager::test::connection_manager_start ... ok

- even though some of them FAILED - doesn't this suggest there is a problem with "RUST_TEST_THREADS=1" ?

[Ghaunt]

"thread 'test_beacon receiver' panicked at 'index out of bounds: the len is 0 but the index is 0', ../src/libcollections/vec.rs:1047"
"thread 'test_avoid_beacon seek_peers 2' panicked at 'index out of bounds: the len is 0 but the index is 0', ../src/libcollections/vec.rs:1047"

You still have the same error with one more. But I guess other threads continue to work.

[philiprhoades]

People,

Some progress:

I had the idea to test everything built on a Fedora 22 Docker image to see if that gave a different result from the VM built on Fedora-Live-Xfce-x86_64-22-3.iso - since Ghaunt had success with Fedora-Live-Workstation-x86_64-22-3.iso and yes, the Docker image works too, which I guess is not so surprising but it at least gives me a convenient method of continuing to test the daily stuff. The problem with the XFCE spin still needs to be tracked down though . .

P.

[vinipsmaker]

This issue is so old. Does it still happens?

The only thing that comes to my mind is a race in this test: https://github.com/maidsafe/crust/blob/ff9f1080e48e70942491ed2a1199cbb02dd9ec22/src/beacon.rs#L330

I think a proper fix is to make t3 wait for t2 to finish instead this racy approach. But I'd like to confirm this error still happens before proposing the fix.

[ustulation]

This crate had a major re-write/re-design. Please raise an issue again if required as almost everything in the library and the way it handled things have changed. Closing this.