frames cannot be resolved on macOS

[winterqt]

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).

[alexcrichton]

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]

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]

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]

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]

The relevant code here is gonna be these two files:

• https://github.com/rust-lang/backtrace-rs/blob/master/src/symbolize/gimli.rs
• https://github.com/rust-lang/backtrace-rs/blob/master/src/symbolize/gimli/libs_macos.rs

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]

Oh there may also be bits in this file as well to debug -- https://github.com/rust-lang/backtrace-rs/blob/master/src/symbolize/gimli/macho.rs

[winterqt]

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]

   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]

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.