Rust, SAFE Network, Crust and a problem for Fedora 22 x86_64 XFCE (ie not other spins)

[Orion Poplawski]

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.

HTH

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                   http://www.nwra.com