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.
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,
Suvayu,
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.
Hope this helps,
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 . .
Oh well . .
Thanks anyway.
Phil.
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?
Hope this helps,
Suvayu,
On 2015-08-28 10:03, Suvayu Ali wrote:
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?
Yes, others had no trouble with other Fedora 22 x86_64 spins and it works fine on a basic F22 Docker image for me.
P.
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.
Suvayu,
On 2015-08-28 20:38, Suvayu Ali wrote:
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.
Thanks - that sounds like a good other option! I will be away for a week now so I will have to look at this again when I get back . .
Thanks all!
Regards,
Phil.
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,
On 2015-08-28 07:17, Orion Poplawski wrote:
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.
Very nice! I will give that a shot!
Thanks a lot.
Regards,
Phil.
-
Orion Poplawski -
Philip Rhoades -
Suvayu Ali