Skip to content

frames cannot be resolved on macOS #443

Closed
@winterqt

Description

@winterqt
Contributor

code

fn main() {
    backtrace::trace(|frame| {
        println!("frame: {:?}", frame);

        // Resolve this instruction pointer to a symbol name
        backtrace::resolve_frame(frame, |symbol| {
            println!("\tname: {:?}", symbol.name());
            println!("\tfilename: {:?}", symbol.filename());
        });

        true // keep going to the next frame
    });
}

output

frame: Frame { ip: 0x1046c2048, symbol_address: 0x1046c2048 }
frame: Frame { ip: 0x1046c2098, symbol_address: 0x1046c2098 }
frame: Frame { ip: 0x1046c1e18, symbol_address: 0x1046c1e18 }
frame: Frame { ip: 0x1046c1a40, symbol_address: 0x1046c1a40 }
frame: Frame { ip: 0x1046c1d98, symbol_address: 0x1046c1d98 }
frame: Frame { ip: 0x1046c1c14, symbol_address: 0x1046c1c14 }
frame: Frame { ip: 0x104780c14, symbol_address: 0x104780c14 }
frame: Frame { ip: 0x1046c1bdc, symbol_address: 0x1046c1bdc }
frame: Frame { ip: 0x1046c1e40, symbol_address: 0x1046c1e40 }

rustc version info

rustc 1.55.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: aarch64-apple-darwin
release: 1.55.0
LLVM version: 12.0.1

backtrace version: 0.3.61

I can also reproduce this with std::backtrace on the nightly from 2021-10-13, but I think this is the most fitting place to file this issue (let me know if it isn't, and I'll open an issue in the Rust repo).

Activity

changed the title [-]frames cannot be resolved[/-] [+]frames cannot be resolved on macOS[/+] on Oct 14, 2021
alexcrichton

alexcrichton commented on Oct 14, 2021

@alexcrichton
Member

Whether or not you can generate a backtrace with fielnames and line numbers can depend on issues like whether you stripped the binary, whether there's debuginfo, etc. Can you detail more about your build process and how to reproduce this? Locally for me on macOS with cargo run --example backtrace in this repository it works.

winterqt

winterqt commented on Oct 14, 2021

@winterqt
ContributorAuthor

Oh, I should've mentioned this: cargo run --example backtrace in this repository doesn't work for me either:

$ cargo run --example backtrace
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/examples/backtrace`
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
alexcrichton

alexcrichton commented on Oct 14, 2021

@alexcrichton
Member

IIRC there's something fiddly about M1 macs where something about the system libraries and/or debuginfo don't live in places they used to. I sort of forget though, and without an M1 I unfortunately can't help debug further :(

winterqt

winterqt commented on Oct 14, 2021

@winterqt
ContributorAuthor

Ah, fun.

I'd be willing to help figure this out. Where should I start looking in the codebase, what handles the system libraries / debuginfo?

alexcrichton

alexcrichton commented on Oct 14, 2021

@alexcrichton
Member

The relevant code here is gonna be these two files:

The best way to figure this out is probably going to be adding some debugging prints to gimli.rs to see where things go wrong, basically why the dwarf context isn't loaded and why files aren't found.

alexcrichton

alexcrichton commented on Oct 14, 2021

@alexcrichton
Member
winterqt

winterqt commented on Oct 14, 2021

@winterqt
ContributorAuthor

The issue is that LC_UUID isn't present.

Now, why is this so? Well, Nix (which is where my toolchain is from) injects -no_uuid into LDFLAGS in a nontrivially reversible way, for the purpose of being able to generate reproducible binaries.

I assume we require the UUID to find the debuginfo? Or is there (hopefully) some workaround we can use if the UUID isn't present? Yup, we can. PR incoming...

winterqt

winterqt commented on Oct 14, 2021

@winterqt
ContributorAuthor
   0: backtrace::backtrace::libunwind::trace
             at src/backtrace/libunwind.rs:93:5
      backtrace::backtrace::trace_unsynchronized
             at src/backtrace/mod.rs:66:5
   1: backtrace::backtrace::trace
             at src/backtrace/mod.rs:53:14
   2: backtrace::capture::Backtrace::create
             at src/capture.rs:176:9
   3: backtrace::capture::Backtrace::new
             at src/capture.rs:140:22
   4: backtrace::main
             at examples/backtrace.rs:4:22
   5: core::ops::function::FnOnce::call_once
             at /private/tmp/nix-build-rustc-1.55.0.drv-0/rustc-1.55.0-src/library/core/src/ops/function.rs:227:5
   6: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /private/tmp/nix-build-rustc-1.55.0.drv-0/rustc-1.55.0-src/library/std/src/sys_common/backtrace.rs:125:18
   7: std::rt::lang_start::{{closure}}
             at /private/tmp/nix-build-rustc-1.55.0.drv-0/rustc-1.55.0-src/library/std/src/rt.rs:63:18
   8: std::rt::lang_start_internal
   9: std::rt::lang_start
             at /private/tmp/nix-build-rustc-1.55.0.drv-0/rustc-1.55.0-src/library/std/src/rt.rs:62:5
  10: <unknown>
             at examples/backtrace.rs:5:2

🎉
Is that last line also <unknown> for you, @alexcrichton? It retrieved the filename and line number correctly, so not sure what's up if that's not the expected output.

alexcrichton

alexcrichton commented on Oct 15, 2021

@alexcrichton
Member

For the last line I get that myself locally as well, and I think it's the inability to trace throuh some system libraries perhaps? I think it's definitely indicative of a bug in any case in this library somewhere because I don't believe it has anything to do with the filename/line number reported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @alexcrichton@winterqt

      Issue actions

        frames cannot be resolved on macOS · Issue #443 · rust-lang/backtrace-rs