Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Backtraces stop at thread boundaries #4066

Open
oli-obk opened this issue Nov 29, 2024 · 3 comments · May be fixed by #4093
Open

Backtraces stop at thread boundaries #4066

oli-obk opened this issue Nov 29, 2024 · 3 comments · May be fixed by #4093
Labels
A-diagnostics errors and warnings emitted by miri C-enhancement Category: a PR with an enhancement or an issue tracking an accepted enhancement E-good-first-issue A good way to start contributing, mentoring is available

Comments

@oli-obk
Copy link
Contributor

oli-obk commented Nov 29, 2024

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
Copy link
Member

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.

@RalfJung RalfJung added C-enhancement Category: a PR with an enhancement or an issue tracking an accepted enhancement E-good-first-issue A good way to start contributing, mentoring is available A-diagnostics errors and warnings emitted by miri labels Nov 29, 2024
@actuallyatoaster
Copy link

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

@RalfJung
Copy link
Member

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

@actuallyatoaster actuallyatoaster linked a pull request Dec 13, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-diagnostics errors and warnings emitted by miri C-enhancement Category: a PR with an enhancement or an issue tracking an accepted enhancement E-good-first-issue A good way to start contributing, mentoring is available
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Allow backtraces to cross thread boundaries actuallyatoaster/miri
3 participants
@RalfJung @oli-obk @actuallyatoaster