By default, RUST_BACKTRACE=1 silently has no effect on Miri, even though it is suggested in panic messages

[matthiaskrgr]

cc rust-lang/rust#98112
cc @saethlin

Code from the pr

fn main() {
    let mut x = [0u32; 2];
    let ptr: *mut u8 = x.as_mut_ptr().cast::<u8>();
    unsafe {
        *(ptr.add(1).cast::<u32>()) = 42;
    }
}

run with RUST_BACKTRACE=1 ~/.cargo/bin/cargo miri run seems to not print any backtrace disregarding what the panic output suggests:

Preparing a sysroot for Miri (target: x86_64-unknown-linux-gnu)... done
WARNING: Ignoring `RUSTC_WRAPPER` environment variable, Miri does not support wrapping.
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `/home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri runner target/miri/x86_64-unknown-linux-gnu/debug/f`
thread 'main' panicked at 'misaligned pointer dereference: address must be a multiple of 0x4 but is 0x278b1', src/main.rs:5:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[deltragon]

Does disabling isolation help?
See https://github.com/rust-lang/miri#note-run-with-rust_backtrace1-environment-variable-to-display-a-backtrace

[saethlin]

There's no bug here, but I do believe we have a diagnostic issue. @matthiaskrgr is a decently experienced Rust and Miri user, if this is too subtle for Matthias it has probably tripped up new Miri users.

@rust-lang/miri Is there a reasonable way to solve this in Miri? I'm tempted to stick something like this into the standard library right after the write! for that note: run with RUST_BACKTRACE=1, but that seems like hacking the library because I can't figure out how to detect this situation inside Miri.

[RalfJung]

Ah... Yeah I think I was also confused by this at least once.^^ We could consider forwarding that env var by default but then default mode is not fully host-independent any more.

[saethlin]

We could also always set it when isolation is enabled. The only potential hazard there is that I have seen one other library check for RUST_BACKTRACE=1 and change behavior (trust-dns-resolver used to include a full backtrace in the Debug impl for its errors when RUST_BACKTRACE was set).

But really what I'm asking is: Can we detect in Miri that we have hit the default panic handler and printed a backtrace, then issue our own little note: after that? My instinct is "no", because that's asking for a lot of details about exactly what library code we executed, but I would like to be sure.

[oli-obk]

We could make default_hook a diagnostic_item and check that in miri. After calling it we could just write another note: to stderr, even if writing to stderr is not 100% the right thing (there's some thread local shenanigans going on).

[RalfJung]

We could also always add some cfg!(miri) code.

[jyn514]

Should this be moved to the rust-lang/miri repo?

[saethlin]

No, 2 of the 3 proposed solutions involve modifying the standard library code.

[RalfJung]

This is a Miri issue, so moving to the Miri repo.

[workingjubilee]

I believe the preferable solution would be to simply ignore the env vars and emit a backtrace while emitting a backtrace due to panic.

[RalfJung]

That seems like an odd difference between regular default and Miri defaults to me.