Closed
Description
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).
Metadata
Metadata
Assignees
Labels
No labels
Activity
[-]frames cannot be resolved[/-][+]frames cannot be resolved on macOS[/+]alexcrichton commentedon Oct 14, 2021
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 commentedon Oct 14, 2021
Oh, I should've mentioned this:
cargo run --example backtrace
in this repository doesn't work for me either:alexcrichton commentedon Oct 14, 2021
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 commentedon Oct 14, 2021
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 commentedon Oct 14, 2021
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 commentedon Oct 14, 2021
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 commentedon Oct 14, 2021
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
intoLDFLAGS
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 commentedon Oct 14, 2021
🎉
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 commentedon Oct 15, 2021
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.