Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

TRUST CI: i686-unknown-linux-musl build hang #529

Closed
posborne opened this issue Feb 26, 2017 · 4 comments
Closed

TRUST CI: i686-unknown-linux-musl build hang #529

posborne opened this issue Feb 26, 2017 · 4 comments

Comments

@posborne
Copy link
Member

This might be a spurious failure or related to the build in general taking too long on travis. Creating this as a general tracking item.

Changes to fix would go into new-ci/master branch for now.

Instance: https://travis-ci.org/berkowski/nix/jobs/205534671
@posborne
Copy link
Member Author

Running locally using cross test --target=i686-unknown-linux-musl, it appear that some of the AIO tests might be hanging...

$ cross test --target=i686-unknown-linux-musl
...
test sys::test_aio::test_aio_write_sigev_signal has been running for over 60 seconds
test sys::test_aio::test_lio_listio_signal has been running for over 60 seconds

CC @asomers. Note that this is prior to your most recent PR.

@asomers
Copy link
Member

asomers commented Feb 26, 2017

https://github.com/japaric/cross says that QEMU "gets upset when you spawn several threads". Those tests technically do spawn several threads, because glibc implements POSIX AIO using threads. It could be a QEMU bug. However, the two tests that hang are the only two that use signals, which suggests that something involving signal delivery is screwed up. In either case, it would be easier to debug if we can get Travis and QEMU out of the picture. Is there a musl-based VM image or installer somewhere that I can spin up in a different hypervisor?

@posborne
Copy link
Member Author

Is there a musl-based VM image or installer somewhere that I can spin up in a different hypervisor?

MUSL binaries should be statically linked, so you should be able to run them in a standard linux environment.

@posborne
Copy link
Member Author

Ok, I did a little more digging on this one and the problem with the new CI is one that we have had in the past relating to concurrency.

By default, cargo will run multiple tests in parallel. When I changed things locally to run with RUST_TEST_THREADS=1, I saw consistent passes with this target. Due to the type of testing we have to do in nix, I will make the change to define this environment variable in CI to avoid these spurious failures.

Here's the original issue where we ran into this before: #292

posborne pushed a commit to posborne/nix-rust that referenced this issue Feb 27, 2017
ci: remove thread parallelism
99dd770 
Fixes nix-rust#529, also refer to
nix-rust#529 which first added this
for the old CI infrastructure.

Signed-off-by: Paul Osborne <ospbau@gmail.com>
@posborne posborne mentioned this issue Feb 27, 2017
Closed
posborne pushed a commit to posborne/nix-rust that referenced this issue Feb 27, 2017
@posborne
ci: remove thread parallelism
ee0ecea 
Fixes nix-rust#529, also refer to
nix-rust#529 which first added this
for the old CI infrastructure.

Signed-off-by: Paul Osborne <ospbau@gmail.com>
posborne added a commit to posborne/nix-rust that referenced this issue Feb 27, 2017
@posborne
ci: remove thread parallelism
d0a151b 
Fixes nix-rust#529, also refer to
nix-rust#529 which first added this
for the old CI infrastructure.

Signed-off-by: Paul Osborne <osbpau@gmail.com>
posborne added a commit to posborne/rust-nix that referenced this issue Feb 27, 2017
@posborne
ci: remove thread parallelism
684bedc 
Fixes nix-rust/nix#529, also refer to
nix-rust/nix#529 which first added this
for the old CI infrastructure.

Signed-off-by: Paul Osborne <osbpau@gmail.com>
homu added a commit that referenced this issue Feb 27, 2017
@homu
Auto merge of #539 - posborne:new-ci/remove-parallelism, r=fiveop
01ccd59 
ci: remove thread parallelism

Fixes #529, also refer to
#529 which first added this
for the old CI infrastructure.
Susurrus pushed a commit that referenced this issue Apr 8, 2017
@posborne @Susurrus
ci: remove thread parallelism
e370059 
Fixes #529, also refer to
#529 which first added this
for the old CI infrastructure.

Signed-off-by: Paul Osborne <osbpau@gmail.com>
Susurrus pushed a commit that referenced this issue Apr 9, 2017
@posborne @Susurrus
ci: remove thread parallelism
a8cf6cb 
Fixes #529, also refer to
#529 which first added this
for the old CI infrastructure.

Signed-off-by: Paul Osborne <osbpau@gmail.com>
@asomers asomers mentioned this issue Apr 15, 2017
Closed
bors bot added a commit that referenced this issue Jan 14, 2019
@bors @thendiscard
Merge #1000
f74befc 
1000: Make nix build again on OpenBSD 6.4-current r=asomers a=thendiscard

First of all, I'm not a rust developer so please be gentle :)

I'm using https://github.com/jwilm/alacritty on OpenBSD. I'm trying to track the latest versions of both OpenBSD and alacritty so I'm recompiling alacritty fairly often. However the latest version of alacritty updated some of it's nix dependencies to v0.12.0 and that doesn't build on OpenBSD anymore:

```bash
user1 ~/ALACRITTY/nix $ sysctl kern.version
kern.version=OpenBSD 6.4-current (GENERIC.MP) #529: Tue Dec 18 22:36:49 MST 2018
    deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

user1 ~/ALACRITTY/nix $ rustc -vV
rustc 1.31.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-openbsd
release: 1.31.0
LLVM version: 6.0

user1 ~/ALACRITTY/nix $ cargo build
    Updating crates.io index
    Updating git repository `https://github.com/rust-lang/libc/`
   Compiling libc v0.2.45 (https://github.com/rust-lang/libc/#027d4834)
   Compiling nix v0.12.0 (/home/user1/ALACRITTY/nix)
   Compiling bitflags v1.0.4
   Compiling cfg-if v0.1.6
   Compiling void v1.0.2
error[E0425]: cannot find function `lutimes` in module `libc`
   --> src/sys/stat.rs:216:15
    |
216 |         libc::lutimes(cstr.as_ptr(), &times[0])
    |               ^^^^^^^ did you mean `futimes`?
help: possible candidate is found in another module, you can import it into scope
    |
1   | use sys::stat::lutimes;
    |

error: aborting due to previous error
```
In order to build nix v0.12.0 on OpenBSD 6.4-current the change in 85ae87c is sufficient, however in order to get the tests to build the 2 additional commits I've included in this PR are required. However even with 680ff30 & 6bdd9f2 the tests build but there is 1 failure:

```bash
user1 ~/ALACRITTY/nix $ cargo build
   Compiling libc v0.2.45 (https://github.com/rust-lang/libc/#027d4834)
   Compiling nix v0.12.0 (/home/user1/ALACRITTY/nix)
   Compiling void v1.0.2
   Compiling cfg-if v0.1.6
   Compiling bitflags v1.0.4
    Finished dev [unoptimized + debuginfo] target(s) in 15.14s

user1 ~/ALACRITTY/nix $ cargo test
   Compiling semver-parser v0.7.0
   Compiling libc v0.2.45
   Compiling rand_core v0.3.0
   Compiling byteorder v1.2.7
   Compiling remove_dir_all v0.5.1
   Compiling lazy_static v1.2.0
   Compiling rand_xorshift v0.1.0
   Compiling rand_hc v0.1.0
   Compiling rand_isaac v0.1.1
   Compiling rand_core v0.2.2
   Compiling semver v0.9.0
   Compiling iovec v0.1.2
   Compiling rand v0.5.5
   Compiling rustc_version v0.2.3
   Compiling bytes v0.4.11
   Compiling rand_chacha v0.1.0
   Compiling rand_pcg v0.1.1
   Compiling rand v0.6.1
   Compiling tempfile v3.0.5
   Compiling nix v0.12.0 (/home/user1/ALACRITTY/nix)
warning: unused import: `nix::sys::signal::*`
 --> test/sys/test_aio_drop.rs:6:5
  |
6 | use nix::sys::signal::*;
  |     ^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(unused_imports)] on by default
< ..................................... >
test sys::time::test::test_timeval_fmt ... ok
test sys::time::test::test_timeval_neg ... ok

test result: ok. 35 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

     Running target/debug/deps/test-6e77230ab75553a1

running 88 tests
test sys::test_ioctl::bsd::test_op_read_64 ... ok
test sys::test_ioctl::bsd::test_op_none ... ok
< ..................................... >
test test_unistd::test_alarm ... ok
test test_unistd::test_canceling_alarm ... ok

failures:

---- sys::test_socket::test_scm_rights stdout ----
thread 'sys::test_socket::test_scm_rights' panicked at 'slice index starts at 24 but ends at 20', libcore/slice/mod.rs:2340:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.


failures:
    sys::test_socket::test_scm_rights

test result: FAILED. 87 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

error: test failed, to rerun pass '--test test'

user1 ~/ALACRITTY/nix $ RUST_BACKTRACE=1 cargo test
< ..................................... >

failures:

---- sys::test_socket::test_scm_rights stdout ----
thread 'sys::test_socket::test_scm_rights' panicked at 'slice index starts at 24 but ends at 20', libcore/slice/mod.rs:2340:5
stack backtrace:
   0: __register_frame_info
   1: __register_frame_info
   2: __register_frame_info
   3: __register_frame_info
   4: __register_frame_info
   5: __register_frame_info
   6: __register_frame_info
   7: __register_frame_info
   8: __register_frame_info
   9: __register_frame_info
  10: __register_frame_info
  11: __register_frame_info
  12: __register_frame_info
  13: __register_frame_info
  14: __register_frame_info
  15: __register_frame_info
  16: __register_frame_info
  17: __register_frame_info
  18: __register_frame_info
  19: __register_frame_info
  20: __register_frame_info
  21: __register_frame_info
  22: __register_frame_info
  23: __register_frame_info
  24: pthread_create


failures:
    sys::test_socket::test_scm_rights

test result: FAILED. 87 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

error: test failed, to rerun pass '--test test'
```

I could add a conditional compilation attribute for `test_scm_rights` but I'm not sure if it's the best option, maybe someone with actual rust skills wants to fix it.

Apart from that 1 failed test nix works fine for me and I can build and use alacritty.

Co-authored-by: Andrei-Marius Radu <thendiscard@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@posborne @asomers