coredump with illegal hardware instruction

[Sherlock-Holo]

I try to use loom to check my project

When I run cargo test --features=concurrent-test --test test, it report

   Compiling atomic_value v0.1.0 (/home/sherlock/git/atomic_value)
    Finished test [unoptimized + debuginfo] target(s) in 0.57s
     Running target/debug/deps/test-6a9029d909e56a54

running 1 test
thread panicked while panicking. aborting.
error: test failed, to rerun pass '--test test'

Caused by:
  process didn't exit successfully: `/home/sherlock/git/atomic_value/target/debug/deps/test-6a9029d909e56a54` (signal: 4, SIGILL: illegal instruction)

Is there anything I write wrong? If have, could anyone help me to fix it?

[hawkw]

This is probably due to a double panic. If a panic occurs while a thread is already unwinding, a ud2 instruction (on x86) is executed, causing the process to be killed with a SIGILL.

Typically (but not always) double panics under loom occur when a test fails, due to an assertion in the test, a panic in the code under test, or loom detecting a model violation. In some cases, when a test panics, cleaning up the loom state for that test will destroy a scoped_thread_local that has already been destroyed, resulting in a second panic.

We'd like to fix this so that loom tests fail with more useful diagnostics. In the meantime, you can run your test with -- --test-threads=1 --nocapture and the RUST_BACKTRACE=1 env var. Then, the panics will still be printed out before your test executable is killed.

Alternatively, double panics can be caused by panics in Drop implementations in the code under test. In this case, you can fix it by ensuring that all Drop implementations in your code will never panic. To find where the panic occurred, the flags I mentioned above are useful in this case as well.

[Sherlock-Holo]

the log is https://fars.ee/kVSp/
I found something

  27: atomic_value::AtomicValue<T>::load
             at ./src/lib.rs:31
  28: test::concurrent_store::{{closure}}::{{closure}}::{{closure}}
             at tests/test.rs:17

in ./src/lib.rs:31 that is

while self.using.compare_and_swap(false, true, Ordering::AcqRel) {}

I read std doc the AtomicBoll allow use AcqRel in compare_and_swap.

The normal unit test that uses std AtomicBool runs well. Do I use loom AtomicBool not right?

[hawkw]

The panic message you posted is:

thread 'main' panicked at 'Model exeeded maximum number of branches. This is often caused by an algorithm requiring the processor to make progress, e.g. spin locks.', /home/sherlock/.cargo/registry/src/mirrors.tuna.tsinghua.edu.cn-df7c3c540f42cdbd/loom-0.3.0/src/rt/path.rs:199:13
stack backtrace:

This means that your code has branched more than 1000 times (the default maximum number of branches that loom will take) before a thread was yielded or preempted. The code you posted here:

while self.using.compare_and_swap(false, true, Ordering::AcqRel) {}

looks like you've essentially implemented a simple spin lock. Are you sure that the spinlock is being released in your test? If not, a thread attempting to lock it might be spinning infinitely. You may want to put a loom::thread::yield_now() or loom::sync::atomic::spin_loop_hint() in the body of the spin loop.

[Sherlock-Holo]

Oh you found it! I miss use spin_loop_hint()

After use this function, the test works well now. Thanks for your help.

[Sherlock-Holo]

Consider the problem solved, this issue can be closed now :)

[cmnord]

Hello, I am also having this issue with my own lock implementation. I put loom::sync::atomic::spin_loop_hint() in the body of the spin loop, but I still get the error Model exeeded maximum number of branches. This is often caused by an algorithm requiring the processor to make progress, e.g. spin locks..

Is adding spin_loop_hint supposed to prevent this panic?