-
Notifications
You must be signed in to change notification settings - Fork 13.3k
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
Labels
A-debuginfo
Area: Debugging information in compiled programs (DWARF, PDB, etc.)
A-diagnostics
Area: Messages for errors, warnings, and lints
Comments
It looks like backtrace_pcinfo() could be used instead of _Unwind_FindEnclosingFunction() + backtrace_syminfo(). I'll attempt it. |
I have an almost working version of this and am working on a PR. Some caveats I've discovered:
|
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> ```
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
When a binary compiled with -g
panic
s, andRUST_BACKTRACE=1
, line numbers should be given along with the backtrace.The text was updated successfully, but these errors were encountered: