Backtraces stop at thread boundaries

[oli-obk]

When an action is performed that miri cannot handle (or UB is hit), the backtrace shown ends at the start of the thread in which the failure happened. As an example

extern {
    fn unknown();
}

fn bad() { unsafe { unknown() } }

fn main() {
    std::thread::spawn(bad);
}

fails with

error: unsupported operation: can't call foreign function `unknown` on OS `linux`
 --> src/main.rs:5:21
  |
5 | fn bad() { unsafe { unknown() } }
  |                     ^^^^^^^^^ can't call foreign function `unknown` on OS `linux`
  |
  = help: if this is a basic API commonly used on this target, please report an issue with Miri
  = help: however, note that Miri does not aim to support every FFI function out there; for instance, we will not support APIs for things such as GUIs, scripting languages, or databases
  = note: BACKTRACE on thread `unnamed-1`:
  = note: inside `bad` at src/main.rs:5:21: 5:30

pointing solely to the function bad.

In this simple example that is not an issue, but if a crate spawns a thread somewhere in its internals, it may not be clear why the thread is even running. I don't think it would be expensive to collect a backtrace at every thread spawn and store this information in the thread data structure itself (as we're not going through the backtrace crate, but just iterating over miri's stack).

[RalfJung]

Yeah that makes sense. We save backtrace for each allocation, we can easily save one for each thread.

Is the plan to always show the backtrace all the way to main? That might get quite long... but it's probably a good first step, and then we can always try to find heuristics for skipping parts of the trace if people complain that the trace is too long.

[actuallyatoaster]

This looks interesting, could I give this a go as a first issue?

[RalfJung]

Yes, definitely. :) Please ask on Zulip if there are any questions.