-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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.
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
macOS symbolication failure #72550
Comments
Assigning |
After reviewing changes to libbacktrace: the new implementation of Mach-O makes |
This is almost surely caused by rust-lang/backtrace-rs#299 which was updated to handle fixes like ianlancetaylor/libbacktrace#32. TBH I can't really keep track of the bugginess and bugfixes in libbacktrace any more. I'm totally lost in what's happening over time. I'm hoping that rust-lang/backtrace-rs#328 can put the nail in this coffin. |
@tmiasko Have you narrowed it down to a specific commit or change? Do you have a sense of how difficult it would be to fix? I ask because an alternative would be to change Cargo so that it does not include the hash in the filename for macOS. It does this already for Windows for similar reasons (Windows embeds the path of the PDB in the executable which causes problems if it has a hash). It's only a minor loss (such as switching between features can cause rebuilds). It sounds like switching to gimli would be great, but probably not going to happen soon? I'm uncertain which approach would be the best approach. |
@ehuss this upgrade switched from Mach-O implementation contributed by John |
@alexcrichton The issue is that the filename inside the dSYM directory includes the hash ( The new implementation does not use Does that seem worth porting the old logic? I'm reluctant to do so, primarily because I'd also like to fix this for 1.45 (far too late for 1.44), and there's only 6 weeks till the next release. I tried with gimli (I assume that's the default for backtrace with no features set?), and it seems to work, though I didn't dig into the source for where that is handled. I don't really have a sense of how annoying hashless executables are (I don't use Windows often enough to have experience with that). Another option is that Cargo could put each executable inside a different directory ( |
Ah ok that definitely makes sense. I think it's best to go with a Cargo fix for this rather than a backtrace one. This would involve editing libbacktrace, which I personally have very little confidence in doing. FWIW the dsym loading for gimli is here. We should probably update gimli to at least only have one level of readdir, not two, but that's a side issue. I think it's fine to avoid hashes on more platforms for Cargo. I agree as well that we can fix this with separate output directories if it becomes a problem. |
Don't hash executable filenames on apple platforms. Due to some recent changes to the backtrace crate, backtraces on apple platforms haven't been working (they are missing line/filename information). The reason is that previously libbacktrace would hunt through the directory for any matching file in the `.dSYM` directory. The new implementation expects a file matching the executable name exactly (which no longer includes the hash because Cargo renames it). The solution here is to not include a hash in the executable filename. This matches the behavior on Windows which does it for a similar reason (paths are embedded in pdb files). The downside is that switching between different settings (like different features) causes Cargo to rebuild the binary each time. I don't think this is a particularly common use case, at least I've not heard any complaints about this behavior on Windows. Fixes rust-lang/rust#72550
I tried this code:
starting with cdb50c6 (nightly-2020-03-26, 1.44), when run with:
results in:
when run with the previous commit, I correctly get the line numbers:
What's interesting, is if you directly run the executable with the metadata hash (like
RUST_BACKTRACE=1 target/debug/deps/foo-f5700d28f7af5060
), the backtrace looks correct. I tried adjusting thedSYM
symlink to include the hash, but that didn't seem to help.I would assume this is due to #70361. cc @tmiasko @alexcrichton
If the filename mismatch doesn't ring any bells, I can maybe try to dig in and see what changed. Although the changes to backtrace-sys look pretty huge, and I'm unfamiliar with it.
The text was updated successfully, but these errors were encountered: