2017-04-09 26 views
2

我使用RUST_BACKTRACE=full ./my-program來運行我編譯的程序。 但是,我收到如下的消息,其中只有不帶行號的功能地址。當我的程序在Rust中被破壞時如何顯示callstack行號?

thread 'main' panicked at 'index out of bounds: the len is 6 but the index is 6', src/libcore/slice/mod.rs:734 
stack backtrace: 
    0:  0x100a26463 - std::sys::imp::backtrace::tracing::imp::unwind_backtrace::hbdeac7eba2f064c6 
    1:  0x100a2786d - std::panicking::default_hook::{{closure}}::h9e0a6ca9bb64b479 
    2:  0x100a27434 - std::panicking::default_hook::h9043ae80af471c9f 
    3:  0x100a29f17 - std::panicking::rust_panic_with_hook::h05996066754c6be9 
    4:  0x100a29e04 - std::panicking::begin_panic::h9fecf34da42eb910 
    5:  0x100a29d22 - std::panicking::begin_panic_fmt::he5aad713258a67c3 
    6:  0x100a29c87 - rust_begin_unwind 
    7:  0x100a4a5f0 - core::panicking::panic_fmt::he26d734b771c5b2c 
    8:  0x100a4a568 - core::panicking::panic_bounds_check::h19dd3f615b4fea05 
    9:  0x100a1fc76 - <usize as core::slice::SliceIndex<[T]>>::index::h1f41340feec36937 
    10:  0x100a1f744 - core::slice::<impl core::ops::Index<I> for [T]>::index::h3246d2321fb7f789 
    11:  0x100a205b6 - sort::merge::h697218a53d5049aa 
    12:  0x100a20227 - sort::merge_sort::h10fe012581f48b43 
    13:  0x100a201e5 - sort::merge_sort::h10fe012581f48b43 
    14:  0x100a201e5 - sort::merge_sort::h10fe012581f48b43 
    15:  0x100a20159 - sort::merge_sort_pub::hb18b616b61510f3b 
    16:  0x100a20e24 - sort::main::hffac78b51f3ea2c3 
    17:  0x100a29c45 - std::panicking::try::do_call::h24a2756282b9a31c 
    18:  0x100a2ba2a - __rust_maybe_catch_panic 
    19:  0x100a2a1d0 - std::rt::lang_start::hd19f94db0c6a490e 
    20:  0x100a20fc9 - main 

是否有任何方法可以在斷點添加行號?

+0

編譯調試信息。也許[libbacktrace](https://github.com/ianlancetaylor/libbacktrace)已被移植或與Rust聯繫。 –

+1

我不確定,但您可能可以使用'rust-gdb'獲取更多信息。確保使用'-g'標誌進行編譯。 – kshikama

+0

@MatthieuM。事實上,作爲[問題](https://github.com/rust-lang/rust/issues/24346#issuecomment-22137581%E2%80%8C%E2%80%8B0)說...似乎linux也有這個問題。但無論:) – wind2412

回答

4

此問題是一個跨平臺問題,並且被追蹤爲Rust issue 24346。我的工作區是macOS 10.12.4:

>rustc -vV 
rustc 1.18.0-nightly (2564711e8 2017-04-04) 
binary: rustc 
commit-hash: 2564711e803f62e04bebf10408cc1c11297c0caf 
commit-date: 2017-04-04 
host: x86_64-apple-darwin 
release: 1.18.0-nightly 
LLVM version: 3.9 

解決方法是使用調試器來獲取調用信息。

我有一個hellobugs.rs文件只出現幾行錯誤代碼。在第3行,我引起恐慌,由於訪問矢量超出範圍:

fn main() {    // 1 
    let v = vec![1, 2, 3]; // 2 
    println!("{}", v[4]); // 3 
}       // 4 

編譯這與rustc hellobugs.rs -g -o hellobugs不要忘了-g說法。

RUST_BACKTRACE=full ./hellobugs一起運行會得到回溯但我的macOS上沒有行號。如問題所述,我們可以使用rust-lldb hellobugs進行調試並獲得詳細的回溯。當然,使用lldb也可以:

>rust-lldb hellobugs 
    ...lots of rust-lldb message... 
(lldb) breakpoint set -b rust_begin_unwind 
Breakpoint 1: where = hellobugs`std::panicking::rust_begin_panic + 4 at panicking.rs:468, address = 0x000000010000a5b4 
(lldb) r 
Process 41626 launched: '/Users/xxx/bin/hellobugs' (x86_64) 
hellobugs was compiled with optimization - stepping may behave oddly; variables may not be available. 
Process 41626 stopped 
* thread #1: tid = 0x6c3e39, 0x000000010000a5b4 hellobugs`std::panicking::rust_begin_panic + 4 at panicking.rs:468, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 
    frame #0: 0x000000010000a5b4 hellobugs`std::panicking::rust_begin_panic + 4 at panicking.rs:468 [opt] 
(lldb) bt 
* thread #1: tid = 0x6c3e39, 0x000000010000a5b4 hellobugs`std::panicking::rust_begin_panic + 4 at panicking.rs:468, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 
    * frame #0: 0x000000010000a5b4 hellobugs`std::panicking::rust_begin_panic + 4 at panicking.rs:468 [opt] 
    frame #1: 0x000000010002af51 hellobugs`core::panicking::panic_fmt + 129 at panicking.rs:69 [opt] 
    frame #2: 0x000000010002aec9 hellobugs`core::panicking::panic_bounds_check + 105 at panicking.rs:56 [opt] 
    frame #3: 0x0000000100001726 hellobugs`collections::vec::{{impl}}::index<i32>(self=0x00007fff5fbff720, index=4) + 118 at vec.rs:1426 
    frame #4: 0x0000000100001826 hellobugs`hellobugs::main + 182 at hellobugs.rs:3 
    frame #5: 0x000000010000a5a6 hellobugs`std::panicking::try::do_call<fn(),()> [inlined] core::ops::FnOnce::call_once<fn(),()> + 6 at ops.rs:2606 [opt] 
    frame #6: 0x000000010000a5a4 hellobugs`std::panicking::try::do_call<fn(),()> + 4 at panicking.rs:454 [opt] 
    frame #7: 0x000000010000c38b hellobugs`panic_unwind::__rust_maybe_catch_panic + 27 at lib.rs:98 [opt] 
    frame #8: 0x000000010000ab31 hellobugs`std::rt::lang_start [inlined] std::panicking::try<(),fn()> + 44 at panicking.rs:433 [opt] 
    frame #9: 0x000000010000ab05 hellobugs`std::rt::lang_start [inlined] std::panic::catch_unwind<fn(),()> at panic.rs:361 [opt] 
    frame #10: 0x000000010000ab05 hellobugs`std::rt::lang_start + 325 at rt.rs:57 [opt] 
    frame #11: 0x000000010000192a hellobugs`main + 42 
    frame #12: 0x00007fffdfc5f235 libdyld.dylib`start + 1 
(lldb) 

我的結果如上。您可以在frame #4處看到at hellobug.rs:3的錯誤結果。這告訴我們第三行有一個錯誤。使用lldb和跟蹤有點麻煩,但它是準確的!

+0

lldb有沒有像gdb的'catch throw'(它捕獲拋出的異常)?這可能比你設置斷點更容易。 –

+0

@MatthieuM。 [這是](http://stackoverflow.com/q/8122375/155423),但我不確定恐慌是否從調試器的角度來看是一個例外。對Rust代碼執行「catch throw」工作嗎? – Shepmaster

+0

FWIW,我打破了'rust_panic' - 如果沒有別的,它少了幾個鍵;-) – Shepmaster

相關問題