Running release tests causes SIGILL

[phodina]

Describe the bug
I'm building ntest 0.7.3 crate for Guix System. The crate itself builds fine. However, when I run the cargo test release the process exits with the SIGILL: illegal instruction.

$ cargo test --release
       Fresh unicode-xid v0.2.1
       Fresh ntest_proc_macro_helper v0.7.3
       Fresh proc-macro2 v1.0.27
       Fresh serde v1.0.123
       Fresh quote v1.0.9
       Fresh toml v0.5.8
       Fresh syn v1.0.72
       Fresh proc-macro-crate v0.1.5
       Fresh ntest_test_cases v0.7.3
       Fresh ntest_timeout v0.7.3
       Fresh ntest v0.7.3 (/tmp/guix-build-rust-ntest-0.7.3.drv-0/ntest-0.7.3)
    Finished release [optimized] target(s) in 0.04s
     Running `/tmp/guix-build-rust-ntest-0.7.3.drv-0/ntest-0.7.3/target/release/deps/ntest-2de355d2c3fb1823`

running 18 tests
test tests::about_equal_f32 ... ok
test tests::assert_false ... ok
test tests::about_equal_f64 ... ok
test tests::assert_false_fails ... ok
test tests::assert_false_trailing_comma ... ok
test tests::assert_panics_fails ... ok
test tests::assert_true ... ok
test tests::assert_panics ... ok
test tests::it_should_not_panic_if_values_are_approx_equal ... ok
test tests::assert_true_fails ... ok
test tests::compare_with_epsilon ... ok
test tests::assert_true_trailing_comma ... ok
test tests::fail_with_epsilon ... ok
test tests::assert_panics_trailing_comma ... ok
test tests::vector_trailing_comma ... ok
test tests::vector_fails ... ok
test tests::vector ... ok
test tests::vector_trailing_comma_with_epsilon ... ok

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

     Running `/tmp/guix-build-rust-ntest-0.7.3.drv-0/ntest-0.7.3/target/release/deps/integration-364ecb9c23d58916`

running 6 tests
error: test failed, to rerun pass '--test integration'

Caused by:
  process didn't exit successfully: `/tmp/guix-build-rust-ntest-0.7.3.drv-0/ntest-0.7.3/target/release/deps/integration-364ecb9c23d58916` (signal: 4, SIGILL: illegal instruction)

To Reproduce
Steps to reproduce the behavior:

1. Run guix import crate -r ntest
2. Store definitions in <guix_repo>/guix/packages/crates-io.scm
3. Build the package guix build -L <guix_repo> rust-ntest
4. See error

Expected behavior
The test would pass.

Screenshots
Here is a backtrace of running in gdb

(gdb) backtrace
#0  0x00005555555703d0 in core::ops::function::Fn::call ()
#1  0x0000555555569442 in std::sys_common::backtrace::__rust_begin_short_backtrace::h014a162e230a3962 ()
#2  0x00005555555712e8 in core::ops::function::FnOnce::call_once{{vtable.shim}} ()
#3  0x00005555555c2a3a in std::sys::unix::thread::Thread::new::thread_start ()
#4  0x00007ffff7facf64 in start_thread ()
   from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0
#5  0x00007ffff7ec59af in clone ()
   from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6

Also as the tests run in parallel I tried to narrow down the issue with running them sequentially:

RUST_TEST_THREADS=1 cargo test --release
running 6 tests
test no_timeout ... ok
test test_function_10 ... ok
test test_function_200 ... ok
test timeout ... ok
test timeout_inf_loop ... error: test failed, to rerun pass '--test integration'

Caused by:
  process didn't exit successfully: `/tmp/guix-build-rust-ntest-0.7.3.drv-0/ntest-0.7.3/target/release/deps/integration-364ecb9c23d58916` (signal: 4, SIGILL: illegal instruction)
``

**Desktop (please complete the following information):**
 - Guix System

[becheran]

@phodina thanks for reporting and sorry for the inconvenience. I am not familiar with guix. Is this some kind of replacement of package manager? Like cargo? Is the failing test you describe somehow reproducible without using guix?

[phodina]

Hi,
sorry for the long delay.

GNU Guix is a package manager similar to Nix.

The "main" idea is to break the Filesystem Hierarchy Standard and store packages in /gnu/store/ or /nix/store.

This is done using prefixes and some modifications. The advantage is that we don't have a global state but each package is independent and we just symlink the whole system together. So we can have multiple version of the package and have generation of the OS therefore we can go always back if we break the system. Also the OS config is simple text config file.

This is very brief and high level overview.

Guix/Nix do follow the package build/test process. So in this case they also use cargo with some additional steps (patching the crates).

• https://guix.gnu.org/manual/en/html_node/Rust-Crates.html
• https://guix.gnu.org/en/blog/2018/bootstrapping-rust/

Is the failing test you describe somehow reproducible without using guix?

Unfortunately I don't have "classical" distro on my laptop. But, I could spin docker container e.g. Alpine or Arch and run the test there to check if it's Guix specific or distro agnostic.

I'll report once this is done, ok?

[becheran]

@phodina thanks for the explanation. I am not directly calling any OS specific functions but since the error ocures in timeout_inf_loop I am pretty sure that this line of code causes trouble:

thread::spawn(move || {
    match sender.send(code()) {
        Ok(()) => {} // All good
        Err(_) => {} // Released, don't panic
    }
});

What version of rust are you using?