On Mon, Aug 24, 2015 at 02:11:32AM +1000, Philip Rhoades wrote: > People, > > I have been getting heavily involved with this project: > > maidsafe.net / maidsafe.org > > and I have a problem (real hardware and VMs) that occurs with building > the > software which doesn't happen for other Fedora 22 spins or if I build > the > software in a Docker image. To reproduce the problem do this: I think you first need to sort out why the tests are failing. For that, rust/crust mailing lists are probably the right place. If the reason turns out to be your environment specific, then you can come back here and ask. As it stands, the only way you will find someone familiar with rust, let alone a crust dev, on this mailing list is purely coincidental. Hope this helps,

On Fri, Aug 28, 2015 at 06:55:50AM +1000, Philip Rhoades wrote: > On 2015-08-27 18:14, Suvayu Ali wrote: > >On Mon, Aug 24, 2015 at 02:11:32AM +1000, Philip Rhoades wrote: > >>People, > >> > >>I have been getting heavily involved with this project: > >> > >> maidsafe.net / maidsafe.org > >> > >>and I have a problem (real hardware and VMs) that occurs with building > >>the > >>software which doesn't happen for other Fedora 22 spins or if I build > >>the > >>software in a Docker image. To reproduce the problem do this: > > > >I think you first need to sort out why the tests are failing. For that, > >rust/crust mailing lists are probably the right place. If the reason > >turns out to be your environment specific, then you can come back here > >and ask. As it stands, the only way you will find someone familiar with > >rust, let alone a crust dev, on this mailing list is purely > >coincidental. > > I have done that of course . . the problem is, no one on those fora > are > interested in sorting out what appears to be a XFCE problem . . What is prompting you/others to conclude it is related to XFCE? It could be any number of things. If your conclusion is based on something, please share it with us. Without complete information it is impossible to suggest something that is specific and useful. For starters, did you try with other desktop environments, or no desktop environment (so, from a tty)? Is it the presence of a specific XFCE package thats the reason, or the environment of an XFCE desktop?

Hi, On Fri, Aug 28, 2015 at 11:01:03AM +1000, Philip Rhoades wrote: > On 2015-08-28 10:03, Suvayu Ali wrote: > > > >For starters, did you try with other desktop environments, or no desktop > >environment (so, from a tty)? Is it the presence of a specific XFCE > >package thats the reason, or the environment of an XFCE desktop? > > Yes, others had no trouble with other Fedora 22 x86_64 spins and it > works > fine on a basic F22 Docker image for me. In that case, you will have to dig into the source. I'm barely familiar with rust, and that too only recently. If I understand the message correctly, the test hangs here: // from vec.rs #[stable(feature = "rust1", since = "1.0.0")] impl<T> Index<usize> for Vec<T> { type Output = T; #[inline] fn index(&self, index: usize) -> &T { // NB built-in indexing via `&[T]` &(**self)[index] // <-- here } } I would run the failing test (see src/beacon.rs:297) inside a debugger and check why the index goes out of range, and why instead of segfaulting[1] it hangs. If you tell me how to run a rust debugger, I can try when I have the time (but kinda hard at the moment). I hope this helps. Footnotes: [1] At least that's what I would expect from C/C++ for index out of bounds problems.

On 08/23/2015 10:11 AM, Philip Rhoades wrote: > People, > > I have been getting heavily involved with this project: > > maidsafe.net / maidsafe.org > > and I have a problem (real hardware and VMs) that occurs with building > the > software which doesn't happen for other Fedora 22 spins or if I build > the > software in a Docker image. To reproduce the problem do this: > > As root: > > curl -sSf https://static.rust-lang.org/rustup.sh | sh -s -- > --channel=nightly > dnf install libsodium-devel > > As any user: > > git clone https://github.com/maidsafe/crust > cd crust > cargo build > RUST_TEST_THREADS=1 cargo test > > You should see something like this: > > > Running target/debug/crust-991e24481699f6b2 > > running 23 tests > test beacon::test::test_avoid_beacon ... ok > test beacon::test::test_beacon ... ok > test bootstrap_handler::test::duplicates ... ok > test bootstrap_handler::test::max_contacts ... ok > test bootstrap_handler::test::oldest ... ok > test bootstrap_handler::test::prune ... ok > test bootstrap_handler::test::serialisation ... ok > test config_utils::test::read_config_file_test ... ok > test connection_manager::test::bootstrap ... ok > test connection_manager::test::bootstrap_off_list_connects ... ok > test connection_manager::test::bootstrap_off_list_connects_multiple > ... ok > test connection_manager::test::connection_manager ... ok > test connection_manager::test::connection_manager_start ... ok > test connection_manager::test::network ... ignored > test getifaddrs::test::test_filter_loopback ... ok > test getifaddrs::test::test_getifaddrs ... ok > test tcp_connections::test::test_multiple_nodes_small_stream ... ok > test tcp_connections::test::test_small_stream ... ok > test test::check_rust_unit_testing_is_not_parallel ... ok > test transport::test::test_ord ... ok > test utp_connections::test::cannot_establish_connection ... NOTE: > Transport > connect 172.17.0.28:56710 failure due to InvalidPacket > NOTE: Transport connect 172.17.0.28:38604 failure due to InvalidPacket > NOTE: Transport connect 172.17.0.28:36980 failure due to InvalidPacket > NOTE: Transport connect 172.17.0.28:37710 failure due to InvalidPacket > NOTE: Transport connect 172.17.0.28:34469 failure due to InvalidPacket > ok > test utp_connections::test::establishing_connection ... ok > test utp_connections::test::send_receive_data ... ok > > test result: ok. 22 passed; 0 failed; 1 ignored; 0 measured > > > Instead for an XFCE environment I see this: > > > Running target/debug/crust-935be27542bb08fc > > 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:1047 > > > - which also hangs indefinitely . . I have NO idea why a desktop > environment > should cause this sort of problem - anyone got any ideas? > > Thanks, > > Phil. This is what I often do to debug these kinds of issues - run each under strace and compare the difference. So something like: RUST_TEST_THREADS=1 strace -f -o /tmp/good cargo test and /tmp/bad for the failing environment. Then you have to strip out the pids, so: sed -e 's/^[0-9]* //' < /tmp/good > /tmp/good.stripped Sometimes I also strip out hex addresses with something like 's/0x[0-9a-f]{4,16}//g'. Then I walk through: diff /tmp/good.stripped /tmp/bad.stripped | less and see where they started to diverge.