Stuck when running cargo miri test

[cicilzx]

I've found that there are times when running cargo miri test, it gets stuck without any information.
Not sure if it's related with rustc/cargo/miri's version, or something else potentially.

I've tried this crate named adler (https://github.com/jonas-schievink/adler):

git clone https://github.com/jonas-schievink/adler
cd adler
# this works well:
cargo test
# this would be stucked:
cargo miri test

Another crate aho-corasick (https://github.com/BurntSushi/aho-corasick), it would stuck at: tests::regression_case_insensitive_prefilter ...

The output is as follows:

Running unittests src/lib.rs (target/miri/x86_64-unknown-linux-gnu/debug/deps/aho_corasick-578e16ba3e218519)

running 163 tests
test nfa::contiguous::tests::swar ... ok
test packed::pattern::tests::equals_different_lengths ... ok
test packed::pattern::tests::equals_mismatch ... ok
test packed::pattern::tests::equals_yes ... ok
test packed::pattern::tests::prefix ... ok
test packed::tests::search_default_leftmost_first ... FAILED
test packed::tests::search_default_leftmost_longest ... FAILED
......
test tests::regression_case_insensitive_prefilter ...

Then there is no response for a long time.

My cargo version is: cargo 1.77.0-nightly (1ae631085 2024-01-17)

[saethlin]

I'm pretty sure Miri is not "stuck" in any sense here; the interpreter is just really slow compared to even a debug build. For this reason, it's common to use cfg(miri) to adjust the amount of work that tests to when compiled/run by Miri. But not all crates do that, and instead run a subset of their test suite under Miri in CI or something like that.

[tiif]

I can attest to this. For aho-corasick's tests::regression_case_insensitive_prefilter, it passed in 2071.56s, which is around 35 minutes.

(Now I really see how slow miri can get...)

[saethlin]

The slowdown is unbounded, currently because of a problem with the provenance GC: #3209
But before that, the slowdown was unbounded due to accumulating garbage :p

I'm going to close this; we already have a lot of issues which are various versions of "Miri is slow" and this one is just another as far as I can tell.

If you want to be doubly sure, you can set MIRI_LOG which contains logging of the interpreter's execution of MIR, or you can use -Zmiri-report-progress which is documented in the README, or you can use -Zmiri-measureme to collect a profile of what Rust code is being executed; we have a ctrl-c handler which will finalize the measureme file.