Skip to content

Include line numbers in backtraces #20978

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

Closed
gsingh93 opened this issue Jan 12, 2015 · 4 comments · Fixed by #22839
Closed

Include line numbers in backtraces #20978

gsingh93 opened this issue Jan 12, 2015 · 4 comments · Fixed by #22839
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) A-diagnostics Area: Messages for errors, warnings, and lints

Comments

@gsingh93
Copy link
Contributor

When a binary compiled with -g panics, and RUST_BACKTRACE=1, line numbers should be given along with the backtrace.

@kmcallister kmcallister added A-diagnostics Area: Messages for errors, warnings, and lints A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) labels Jan 12, 2015
@brooksbp
Copy link
Contributor

It looks like backtrace_pcinfo() could be used instead of _Unwind_FindEnclosingFunction() + backtrace_syminfo(). I'll attempt it.

@lifthrasiir
Copy link
Contributor

I have an almost working version of this and am working on a PR. Some caveats I've discovered:

  • It will only work in non-Android POSIX as it depends on libgcc and libbacktrace.
  • We really need _Unwind_GetIPInfo instead of _Unwind_GetIP to determine if given IP is a non-signaling frame (thus the IP is located after the calling instruction). GCC 4.2.0 or later has this, so it should be fine, but we need a workaround for non-libgcc paths.
  • backtrace_pcinfo can be called multiple times for inlined calls. For the convenience I have 32 calls limit right now.
  • Macros somehow replaces the file/line information for given frame, which makes a test quite annoying. panic!() for example will replace the last user frame with <std macros>:3 instead of a line invoking the macro. Really an issue at its own.

@brooksbp
Copy link
Contributor

I was having difficultly ramping up on Rust's FFI and did not make much progress on this. @lifthrasiir Looking forward to your work.

lifthrasiir added a commit to lifthrasiir/rust that referenced this issue Feb 26, 2015
Fixes rust-lang#20978 for supported platforms (i.e. non-Android POSIX).

This uses `backtrace_pcinfo` to inspect the DWARF debug info
and list the file and line pairs for given stack frame.
Such pair is not unique due to the presence of inlined functions
and the updated routine correctly handles this case.
The code is modelled after libbacktrace's `backtrace_full` routine.

There is one known issue with this approach. Macros, when invoked,
take over the current frame and shadows the file and line pair
which has invoked a macro. In particular, this makes many panicking
macros a bit harder to inspect. This really is a debuginfo problem,
and the backtrace routine should print them correctly with
a correct debuginfo.
bors added a commit that referenced this issue Feb 28, 2015
Fixes #20978 for supported platforms (i.e. non-Android POSIX).

This uses `backtrace_pcinfo` to inspect the DWARF debug info and list the file and line pairs for given stack frame. Such pair is not unique due to the presence of inlined functions and the updated routine correctly handles this case. The code is modelled after libbacktrace's `backtrace_full` routine.

There is one known issue with this approach. Macros, when invoked, take over the current frame and shadows the file and line pair which has invoked a macro. In particular, this makes many panicking
macros a bit harder to inspect. This really is a debuginfo problem, and the backtrace routine should print them correctly with a correct debuginfo.

Some example trace:

```
thread '<main>' panicked at 'explicit panic', /home/arachneng/Works/git/rust/src/test/run-pass/backtrace-debuginfo.rs:74
stack backtrace:
   1:         0xd964702f - sys::backtrace::write::h32d93fffb64131b2yxC
   2:         0xd9670202 - panicking::on_panic::h3a4fcb37b873aefeooM
   3:         0xd95b396a - rt::unwind::begin_unwind_inner::h576b3df5f626902dJ2L
   4:         0xd9eb88df - rt::unwind::begin_unwind::h16852273847167740350
   5:         0xd9eb8afb - aux::callback::h15056955655605709172
                        at /home/arachneng/Works/git/rust/<std macros>:3
                        at src/test/run-pass/backtrace-debuginfo-aux.rs:15
   6:         0xd9eb8caa - outer::h2cf96412459fceb6ema
                        at src/test/run-pass/backtrace-debuginfo.rs:73
                        at src/test/run-pass/backtrace-debuginfo.rs:88
   7:         0xd9ebab24 - main::h3f701287441442edasa
                        at src/test/run-pass/backtrace-debuginfo.rs:134
   8:         0xd96daba8 - rust_try_inner
   9:         0xd96dab95 - rust_try
  10:         0xd9671af4 - rt::lang_start::h7da0de9529b4c394liM
  11:         0xd8f3aec4 - __libc_start_main
  12:         0xd9eb8148 - <unknown>
  13:         0xffffffff - <unknown>
```
@kornelski
Copy link
Contributor

Oops, I've filed a duplicate #24346, because it doesn't work for me in rustc 1.0.0-nightly (6436e34 2015-04-08) (built 2015-04-08)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) A-diagnostics Area: Messages for errors, warnings, and lints
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants