Miri test fails with thread_local storage

[Robbepop]

I started testing my PRs using miri via cargo miri test.
In general it is an amazing tool and I already found some undefined behavior using it.

However, in some tests cargo test succeeds and yields ok for a test whereas cargo miri test yields in FAILED.

Example

Let's look at the PR: https://github.com/paritytech/ink/tree/redo-init-and-flush
Running cargo test should yield that all tests are fine.
However, running cargo miri test -- -- key_add yields the following:

running 2 tests
test env::engine::off_chain::tests::key_add ... ok
test env::engine::off_chain::tests::key_add_sub ... FAILED

failures:

---- env::engine::off_chain::tests::key_add_sub stdout ----
Error: OffChain(TypedEncoded(AlreadyInitialized { initialized_id: TypeId { t: 596591791173715099 }, new_id: TypeId { t: 596591791173715099 } }))
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `0`: the test returned a termination value with a non-zero status code (1) which indicates a failure', /home/robrob/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/macros.rs:16:9

Interesting fun fact: When we just test key_add_sub without key_add it starts to work fine as well:

running 1 test
test env::engine::off_chain::tests::key_add_sub ... ok

The output points to some entity that sits behind a thread local storage.
It seems that those tests have some shared state when using miri which causes them to fail.

[RalfJung]

Could you try cargo test with just a single thread (cargo test -- --test-threads=1)? If your tests are using thread-local storage, maybe they are (incorrectly) relying on each test being run in a separate thread.

[Robbepop]

Could you try cargo test with just a single thread (cargo test -- --test-threads=1)? If your tests are using thread-local storage, maybe they are (incorrectly) relying on each test being run in a separate thread.

This actually is the problem ... thanks!
However, is there a way to run tests using miri each in their own thread?
Anyways, good that this has been revealed and it has been fixed already - now miri no longer fails for those tests. :)

[oli-obk]

Yes, but it's WIP: #1284

[Robbepop]

Sounds great!
I really want to integrate miri into our project's CI as soon as I get it working fully.
This issue can be closed, now.

---

A bit off-topic but: miri found another potential problem with stacked borrows at some other part of the codebase but I really fail to see the source of the problem with the pointed out code. As mentioned in some other issue debugging stacked borrow warnings is quite hard. Are there some general guidelines how to approach debugging these kind of things? In case you are curious I can also open another issue.

[oli-obk]

Have a look at the flags with track in their name at https://github.com/rust-lang/miri#miri--z-flags-and-environment-variables

Please open issues if you run into troubles with them or need more specific flags our output to help you debug.

[RalfJung]

In general it is an amazing tool and I already found some undefined behavior using it.

Btw, if you would like to share that bug and add it to our trophy case, a PR would be very welcome. :)

[Robbepop]

Does the trophy also count if I was already having a suspicion about the code in question and then ran miri on it in order to prove my assumption (which it sadly did)? Btw.: To me miri is one of the most amazing tools (not only for Rust) and I am sure it will make the difference in safety critical applications in the future.

[RalfJung]

Hm... not sure.^^ So far we collected bugs that actually made it into a release, or at least into the master branch of a repo.

Thank you so much for your kind words about Miri, this is the kind of feedback that motives me to keep working on it. :)