-
Notifications
You must be signed in to change notification settings - Fork 328
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Miri hangs when a test failed #2273
Comments
I'm trying to use this as a test case and now the test in question is passing. Here's a useful program: fn main() {
leaf(100);
}
fn leaf(x: usize) {
if x == 0 {
panic!("ouch");
}
leaf(x - 1);
}
#[test]
fn oof() {
panic!("ouch");
} So based on this, the stack depth is irrelevant ( I actually added the backtraces bench-cargo-miri project to target this general situation, and at the time I didn't realize there are two different problems here. More motivation to go deal with that rebase I guess :p |
There are? |
Ah sorry, speaking from my particular perspective on SB performance 😅 From what I recall, just the However, that PR does finish running these tests in ~46 seconds which makes it a >10x speedup over the current situation. Which I think is due to a big speedup along the code path you pointed out. Though we'll know for sure when I get around to rebasing the PR. |
I made a PR that changes |
Here is another fun program: fn main() {
let x: &[u8] = &[0u8; 256];
let start = std::time::Instant::now();
for i in 0..x.len() {
//let _item = unsafe { *x.get_unchecked(i) };
let _item = x[i];
}
println!("{:?}", start.elapsed());
let x: &[u8] = &[0u8; 512];
let start = std::time::Instant::now();
for i in 0..x.len() {
//let _item = unsafe { *x.get_unchecked(i) };
let _item = x[i];
}
println!("{:?}", start.elapsed());
let x: &[u8] = &[0u8; 1024];
let start = std::time::Instant::now();
for i in 0..x.len() {
//let _item = unsafe { *x.get_unchecked(i) };
let _item = x[i];
}
println!("{:?}", start.elapsed());
} On my machine, this prints:
Very reasonable, ~2x increase in runtime per doubling of the array size.
That's more like a ~8x increase per doubling of the array size. Ouch. If I stick in a Also, So if I had to go for a minimal diff to address the backtrace printing issue, hoist the length and a pointer to the slice into a local outside of the loop, and use pointer arithmetic to read each element in the ASCII path instead of calling I would really like to do something about this on the Miri end, but I'm not sure what to do. The debugging support I slapped together to figure out what tags are being added might be a start? |
What happens with something like this? let elem = &x[i];
let _item = *elem; Then we do still get a reborrow for each iteration. But we avoid the large reborrow of |
Same runtimes within noise as |
Note that with I think there is, in theory, an optimization we can do here, but I am not sure how practical it is. |
Add a benchmark of the hang-on-test-failure code path This is the code pattern that produces the performance problem in #2273 I figured out what I was stuck on in #2315 (comment). For a while I was just doing `let x: &[u8] = &[0u8; 4096];` but that doesn't produce the runtime inside `Stack::item_popped` that I was looking for, I think because this allocation is never deallocated. But with `Vec`, I get the profile I'm looking for.
…mulacrum Update backtrace Most notably, this pulls in rust-lang/backtrace-rs@ebc9a85, which is both a bugfix and a significant performance improvement for Miri, since fixing the bug makes `RUST_BACKTRACE=1` backtraces much smaller: rust-lang/miri#2273, rust-lang/miri-test-libstd#8 This also pulls in other commits which turn the backtrace-rs CI green. That's nice.
Update backtrace Most notably, this pulls in rust-lang/backtrace-rs@ebc9a85, which is both a bugfix and a significant performance improvement for Miri, since fixing the bug makes `RUST_BACKTRACE=1` backtraces much smaller: rust-lang/miri#2273, rust-lang/miri-test-libstd#8 This also pulls in other commits which turn the backtrace-rs CI green. That's nice.
Between the stack cache and the tag GC, on my machine Miri will execute a simple Cargo project with a test that just panics in 2.3 seconds with |
Yeah agreed. What does this program with square bracket indexing now print (without isolation)? |
|
Sorry, I meant with get_unchecked. For me that shows
So, it's still super-linear, but it's a lot better than before. Awesome! |
Is it super-linear? I see this
Which is almost exactly doubling of runtime when we double the size of the array. (I would not expect the tag GC to fix all such cases of super-linear behavior, it's a bit conservative and there's also the RangeMap splitting) |
The "time divided by array size" in my measurement is
🤷 |
When a test failed (not with UB, but with a regular assertion failure), and libtest goes to print the failed tests, something goes wrong and Miri just hangs. I am not sure if this always happens, but I just got it in crossbeam and I seem to recall @saethlin also mentioning this.
To reproduce:
MIRIFLAGS="-Zmiri-disable-isolation" cargo +miri miri test -p crossbeam-utils -- wait_and_drop
Using
-Zmiri-progress-report
, I can tell that interpretation itself grinds to a halt -- usually it should print progress every few seconds, but it doesn't, since operations seem to start taking a lot longer. By reducing the progress interval I got this backtrace:Possibly #1935 will help.
The text was updated successfully, but these errors were encountered: