Should have option to report progress

[ralfbiedert]

Background

We have a larger code base in which we combine a number of 'safe' dependencies. After adding another crate we now get a very reproducible SIGILL across different platforms and Rust nightly versions (nightly is mandated by another dependency b/c SIMD). Our code is #[deny(unsafe_code)], but some of our dependencies unfortunately juggle with it.

The bug is very easy to reproduce in our project, but I was, so far, unsuccessful isolating it.

At this point I turned to miri for help.

Problem

Running our test case via cargo miri test on my machine runs for 1h+ and takes up all the 32GB RAM I have. It then proceeds to use swap space, making the machine practically unusable.

I wouldn't mind that, if there were some indication of progress that allowed me to

• verify it's still doing something sensible
• estimate how long it will take in general

Providing an indication if the evaluation will ever halt, and printing an ETA, would be my preferred solution. Alternatively, maybe an option (--verbose?) to print regular "status updates", execution stack traces ("I'm currently running main() -> g()), ... could also be helpful.

[bjorn3]

nightly is mandated by another dependency b/c SIMD

SIMD works on stable since 1.27 using code::arch. Is it using the nightly only packed_simd crate?

Edit: saw https://github.com/ralfbiedert/ffsvm-rust, which I think you are refering to. It indeed uses packed_simd. If you want to port it to core::arch be aware that the later has a lot less pretty api, as it just exposes the same arch specific intrinsics as you would use for C/C++.

I wouldn't mind that, if there were some indication of progress

libtest normally prints a message after every executed test.

estimate how long it will take in general

That would be equivalent to solving the halting problem. Even a very rough aproximation would be hard to give.

Running our test case via cargo miri test on my machine runs for 1h+

Maybe try to find the exact failing test using nornal execution first, and then run only that test in miri using cargo miri test -- <test name>. Even when doing that you can expect at huge slowdown from running in miri.

Alternatively, maybe an option (--verbose?) to print regular "status updates", execution stack traces ("I'm currently running main() -> g()), ... could also be helpful.

👍

[ralfbiedert]

SIMD works on stable since 1.27 using code::arch. Is it using the nightly only packed_simd crate?

Yes, packed_simd via ffsvm is what forces us on nightly right now.

libtest normally prints a message after every executed test.

I already disabled every other unit test. It's only trying to run the one that has issues.

That would be equivalent to solving the halting problem. Even a very rough aproximation would be hard to give.

Yeah, sorry, the joke got a bit lost on that one :)

Maybe try to find the exact failing test using nornal execution first, and then run only that test in miri using cargo miri test -- . Even when doing that you can expect at huge slowdown from running in miri.

Yes, this is sort of what we are doing already. It's somewhat deep down the call stack and it's doing lots of math. I would love to isolate it more but was unsuccessful so far triggering the bug.

[bjorn3]

Have you tried santizers like valgrind, asan, ubsan, ...? Those have a lot less overhead than miri.

[oli-obk]

Alternatively, maybe an option (--verbose?) to print regular "status updates", execution stack traces ("I'm currently running main() -> g()), ... could also be helpful.

This is totally doable and fairly easy to implement.

Essentially cause a report in https://github.com/rust-lang/miri/blob/master/src/machine.rs#L265 if enough time has passed (needs a new variable for time measurements in the evaluator (

miri/src/machine.rs

Line 78 in bfd6181

pub struct Evaluator<'tcx> {

)

[RalfJung]

Yeah, sorry, the joke got a bit lost on that one :)

If you put in a joke without any indication that it is one, don't expect people to see your wink.
So, please just add a smiley next time. ;)

Essentially cause a report in https://github.com/rust-lang/miri/blob/master/src/machine.rs#L265 if enough time has passed (needs a new variable for time measurements in the evaluator

Or maybe every n-th step, print the topmost N functions on the stack, or so. Yeah, that seems reasonable.