Line numbers in backtrace still do not appear on macOS for Cargo projects

[kennytm]

Repro steps:

1. Create a cargo project.

   cargo new --bin a && cd a && echo 'fn main() { panic!(); }' > src/main.rs 

2. Run it. Note that the line numbers are missing (unexpected).

   RUST_BACKTRACE=1 cargo run

   Output

   thread 'main' panicked at 'explicit panic', src/main.rs:1:12
   stack backtrace:
      0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
      1: std::sys_common::backtrace::_print
      2: std::panicking::default_hook::{{closure}}
      3: std::panicking::default_hook
      4: std::panicking::rust_panic_with_hook
      5: std::panicking::begin_panic
      6: a::main
      7: __rust_maybe_catch_panic
      8: std::rt::lang_start
      9: main
   

3. Run the actual hard-linked program. The line numbers now appear (expected).

   RUST_BACKTRACE=1 target/debug/deps/a-*

   Output

   thread 'main' panicked at 'explicit panic', src/main.rs:1:12
   stack backtrace:
      0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
                at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
      1: std::sys_common::backtrace::_print
                at src/libstd/sys_common/backtrace.rs:71
      2: std::panicking::default_hook::{{closure}}
                at src/libstd/sys_common/backtrace.rs:60
                at src/libstd/panicking.rs:381
      3: std::panicking::default_hook
                at src/libstd/panicking.rs:397
      4: std::panicking::begin_panic
                at src/libstd/panicking.rs:577
      5: std::panicking::begin_panic
                at /Users/travis/build/rust-lang/rust/src/libstd/panicking.rs:538
      6: a::main
                at src/main.rs:1
      7: panic_unwind::dwarf::eh::read_encoded_pointer
                at src/libpanic_unwind/lib.rs:99
      8: rust_panic
                at src/libstd/panicking.rs:459
                at src/libstd/panic.rs:361
                at src/libstd/rt.rs:59
      9: a::main
   

The problem is that in rust-lang/rust#44251 we did not search for the deps/ folder. The fix is either,

1. Symlink target/debug/deps/a-«hash».dSYM to target/debug/a-«hash».dSYM (actual name irrelevant), don't touch libstd. This may also fix No deterministic/easily findable name for debug symbol directory on macOS #4056; or
2. Amend Add libbacktrace support for Apple platforms (resubmitted) rust#44251 to look for deps/ as well, don't touch cargo.

cc @JohnColanduoni

---

Meta

$ cargo -vV
cargo 0.23.0-nightly (33250c48b 2017-09-09)
release: 0.23.0
commit-hash: 33250c48b4763b01478d780e76206484a1d5b207
commit-date: 2017-09-09

$ rustc -vV
rustc 1.22.0-nightly (539f2083d 2017-09-13)
binary: rustc
commit-hash: 539f2083de809b5c8304fe7426655cfeb0e66d5e
commit-date: 2017-09-13
host: x86_64-apple-darwin
release: 1.22.0-nightly
LLVM version: 4.0

[alexcrichton]

I think Cargo can definitely manage lifting this directory up a level, but currently nothing in Rust knows about it (neither Cargo nor rustc itself). This is the same way for a number of debug files on Windows where rustc/cargo only know about a subset of the artifacts, not everything together. I'm under the impression, though, that there's an API that's typically used on OSX to find this information and just doesn't work when spotlight is turned off (who knew?) and maybe that should be called?

[JohnColanduoni]

@alexcrichton

There is such an API (which lldb and gdb use) in the DebugSymbols framework but like CoreSymbolication it's a private API. If we're willing to lean on that I think it might be better to just use CoreSymbolication from start to finish (weakly linked or via dlsym).

[kennytm]

The risk of using private APIs are:

1. It is unstable. But AFAIK the CoreSymbolication API don't change a lot. Not sure about DebugSymbols.
2. Depending on how smart Apple's auto checker is, you may not be able to distribute the program to App Store (both Mac and iOS, see Mac app store build uses non-public APIs  electron/electron#8555)

Unless there's a way to entirely strip off the CoreSymbolication/DebugSymbols part in release build (leaving only dladdr-based backtrace), I don't recommend using the private APIs.

[alexcrichton]

Ah that's a bummer :( But yeah I think we should avoid these sorts of APIs in libstd. Maybe a "hack" that's specific to Cargo then?

[gilescope]

We're so close to something that works 'out-of-the-box' for OSX...

[gilescope]

For intelliRust people reading this, you can add an external tool that's run before launch. Getting it to kick off cp works:

cp
-R $ProjectFileDir$/target/debug/deps/ $ProjectFileDir$/target/debug/

(using the arg -n as well is faster but gives a non-zero error code second time around so you might want to put this in a script as intellirust won't continue otherwise.)
(Also you migth want to break the compile and run into two seperate steps as otherwise you'll always get the line numbers of the prior compile..)

[kennytm]

I think we could do the lift-up *.dSYM thing after #4570 is merged.

@gilescope Symlink should be enough, no need to copy unless symlink fails.

[kennytm]

Just to note that I'm currently working on fixing this (uplift the dSYM).