Line numbers absent in panic stack traces

[ApoorvaJ]

I am unsure whether this is a bug, a limitation, or me making a mistake somewhere.

Summary

If code panics, I do not get line numbers in the stack trace. I am using the console_error_panic_hook crate.

Observed output

On Firefox 65, I get the following output:

panicked at 'Element with id 'non_existent_id' not found.', src/libcore/option.rs:1008:5

Stack:

__exports.__wbg_new_a99726b0abef495b@http://127.0.0.1:3030/index.js:52:30
console_error_panic_hook::Error::new::hb2b92901807268c5@http://127.0.0.1:3030/index_bg.wasm:wasm-function[222]:0x11dae
console_error_panic_hook::hook_impl::h7fc2248b8900837d@http://127.0.0.1:3030/index_bg.wasm:wasm-function[59]:0x90f6
console_error_panic_hook::hook::h00f6b5e3ca455954@http://127.0.0.1:3030/index_bg.wasm:wasm-function[407]:0x15f9b
core::ops::function::Fn::call::ha501188f6ae2c625@http://127.0.0.1:3030/index_bg.wasm:wasm-function[380]:0x158eb
std::panicking::rust_panic_with_hook::h869ce4541d4e3554@http://127.0.0.1:3030/index_bg.wasm:wasm-function[98]:0xc48f
std::panicking::continue_panic_fmt::h0ad726c0b188da91@http://127.0.0.1:3030/index_bg.wasm:wasm-function[258]:0x12e60
rust_begin_unwind@http://127.0.0.1:3030/index_bg.wasm:wasm-function[564]:0x1782b
core::panicking::panic_fmt::h4d67173bc68f6d5a@http://127.0.0.1:3030/index_bg.wasm:wasm-function[390]:0x15b8f
core::option::expect_failed::h2f881c519f1d8001@http://127.0.0.1:3030/index_bg.wasm:wasm-function[279]:0x13747
<core::option::Option<T>>::expect::h5feaee6e9f7423d8@http://127.0.0.1:3030/index_bg.wasm:wasm-function[127]:0xe02a
index::get_element::h86f485cc52c3c6a2@http://127.0.0.1:3030/index_bg.wasm:wasm-function[58]:0x9065
index::main::hf43b95ff830341a6@http://127.0.0.1:3030/index_bg.wasm:wasm-function[83]:0xb28e
main@http://127.0.0.1:3030/index_bg.wasm:wasm-function[175]:0x10379
init/<@http://127.0.0.1:3030/index.js:180:5

On Chrome 72, I get the following output:

index.js:31 panicked at 'Element with id 'non_existent_id' not found.', src/libcore/option.rs:1008:5

Stack:

Error
    at __exports.__wbg_new_a99726b0abef495b (http://127.0.0.1:3030/index.js:52:30)
    at console_error_panic_hook::Error::new::hb2b92901807268c5 (wasm-function[222]:34)
    at console_error_panic_hook::hook_impl::h7fc2248b8900837d (wasm-function[59]:99)
    at console_error_panic_hook::hook::h00f6b5e3ca455954 (wasm-function[407]:38)
    at core::ops::function::Fn::call::ha501188f6ae2c625 (wasm-function[380]:45)
    at std::panicking::rust_panic_with_hook::h869ce4541d4e3554 (wasm-function[98]:265)
    at std::panicking::continue_panic_fmt::h0ad726c0b188da91 (wasm-function[258]:116)
    at rust_begin_unwind (wasm-function[564]:3)
    at core::panicking::panic_fmt::h4d67173bc68f6d5a (wasm-function[390]:70)
    at core::option::expect_failed::h2f881c519f1d8001 (wasm-function[279]:111)


__exports.__wbg_error_f7214ae7db04600c @ index.js:31
wasm-0000006e:578 Uncaught (in promise) RuntimeError: unreachable
    at __rust_start_panic (wasm-function[577]:1)
    at rust_panic (wasm-function[495]:31)
    at std::panicking::rust_panic_with_hook::h869ce4541d4e3554 (wasm-function[98]:304)
    at std::panicking::continue_panic_fmt::h0ad726c0b188da91 (wasm-function[258]:116)
    at rust_begin_unwind (wasm-function[564]:3)
    at core::panicking::panic_fmt::h4d67173bc68f6d5a (wasm-function[390]:70)
    at core::option::expect_failed::h2f881c519f1d8001 (wasm-function[279]:111)
    at <core::option::Option<T>>::expect::h5feaee6e9f7423d8 (wasm-function[127]:104)
    at index::get_element::h86f485cc52c3c6a2 (wasm-function[58]:349)
    at index::main::hf43b95ff830341a6 (wasm-function[83]:193)

In both of these, Rust line numbers are absent from the wasm functions. Assuming get_element was a large function, how do I tell which line the error came from?

Minimal repro

lib.rs:

extern crate wasm_bindgen;
extern crate web_sys;
extern crate console_error_panic_hook;

use wasm_bindgen::prelude::*;
use web_sys::{Document, Element};

fn get_element(document: &Document, id: &str) -> Element {
    document.get_element_by_id(id)
        .expect(&format!("Element with id '{}' not found.", id))
}

#[wasm_bindgen(start)]
pub fn main() -> Result<(), JsValue> {
    console_error_panic_hook::set_once();

    let window = web_sys::window().expect("no global `window` exists");
    let document = window.document().expect("should have a document on window");

    let _foo = get_element(&document, "non_existent_id");

    Ok(())
}

Cargo.toml:

[package]
name = "foo"
version = "0.1.0"
edition = "2018"

[lib]
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = "0.2"
console_error_panic_hook = "0.1.6"

[dependencies.web-sys]
version = "0.3.4"
features = [
  'Document',
  'Element',
  'HtmlElement',
  'Node',
  'Window',
]

Compiled with cargo build and then wasm-bindgen --no-modules --no-typescript target/wasm32-unknown-unknown/debug/index.wasm --out-dir target/wasm32-unknown-unknown/debug/. Served with a simple HTML page:

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8" lang="en">
    </head>
    <body>
        
    <script src='./index.js'></script>
    <script>
      window.addEventListener('load', async () => {
          await wasm_bindgen('./index_bg.wasm');
      });
    </script>
 </body>
</html>

System details

rustc 1.32.0 (9fda7c223 2019-01-16) (Stable)
wasm-bindgen 0.2.37
64-bit Ubuntu 18.04 LTS

[alexcrichton]

Thanks for the report! Unfortunately this is something we can't currently work around with WebAssembly. There's bits and pieces of source map support for WebAssembly files but we don't think it's quite there yet to support debugging like this.

This is definitely on our roadmap for pushing browsers to support though, and we're ensuring that there's support in wasm-bindgen for threading this information through! This is a big undertaking on our part because tools like wasm-bindgen need to preserve DWARF debug information throughout its transformations.

[alexcrichton]

I'm gonna go ahead and close this in the meantime because there's not much we can do to fix it at this time, but once it's possible to do this in browsers we'll be sure to jump on it as quick as we can!

[noxabellus]

Any update on this re: https://developers.google.com/web/updates/2019/12/webassembly ?

[alexcrichton]

All wasm-bindgen modules in debug mode already have dwarf info so should work natively with any developer tools that parse DWARF debug information. Release-mode modules can retain debug information with --keep-debug but it is removed by default.

[noxabellus]

Oh really? I was under the impression that there is still work to be done here given that the author of that article directly pointed to bindgen as an example of something that wont work yet:

There is still quite a bit of work to do though. For example, on the tooling side, Emscripten (Binaryen) and wasm-pack (wasm-bindgen) don’t support updating DWARF information on transformations they perform yet. For now, they won’t benefit from this integration.

[alexcrichton]

Oh right yeah, forgot about that! Raw wasm modules work but wasm-bindgen doesn't preserve debuginfo throughout its transformations, so line numbers still aren't available.

[solomatov]

@alexcrichton And what is required from wasm-bindgen to preserve this information? Is it hard to implement? Is it on your roadmap?

[alexcrichton]

@solomatov the next major piece of work is to get DWARF parsing into walrus and apply a dwarf transformation pass to generate new DWARF after wasm-bindgen's transformations. AFAIK it's somewhat significant to implement, but @yurydelendik would know more than I about precisely what needs to be done.

[yurydelendik]

In addition to the above, the JS stack traces needs to be adjusted, via looking up the .debug_lines custom section. Notice that the JS engines output "index_bg.wasm:wasm-function[222]:0x11dae" or "(wasm-function[222]:34)", and currently don't look up DWARF tables.

[L-as]

rustwasm/walrus#244 has been merged, perhaps this can be resumed?

[daxpedda]

See #3483 for current work on this.

[andrewbaxter]

AFAICT everything's merged here, and it's been a bit more than half a year so I assume it's all been released, but I'm still getting backtraces with no line numbers. What's required to use this feature (flag on cargo or wasm-bindgen, helper crates, special invocations, etc)? And also, what's not required to use this feature (i.e. is console-panic-error-hook still needed)?

Sorry if this is off topic - read the linked MRs but couldn't get a feel of the big picture implications. Maybe discussion is continuing somewhere else?

FWIW, sans-console-panic-error-hook I just get

__wbg_error_f851667af71bcfc6 https://abc/pos.js:314
    h7f37ac30d77b6b81 https://abc/pos_bg.wasm:758458
    hc9dc71a7551fd371 https://abc/pos_bg.wasm:512325
    hac3cbea2f46d6f91 https://abc/pos_bg.wasm:889691
    h926f0fffdf3c0b7f https://abc/pos_bg.wasm:864102
    h6731baa78621a747 https://abc/pos_bg.wasm:677496
    hb6cd8464ed39ae71 https://abc/pos_bg.wasm:735326
    hbdf3ddeb21a1e747 https://abc/pos_bg.wasm:911172
    rust_begin_unwind https://abc/pos_bg.wasm:873886
    h5c7ce52813e94bcd https://abc/pos_bg.wasm:885587
    h4ed86702351a3017 https://abc/pos_bg.wasm:774537
    h898bf787e227399d https://abc/pos_bg.wasm:174674
    h0d3311f3a87a741a https://abc/pos_bg.wasm:244784
    pos-d3f9a9396ac6ace6.wasm.<core::pin::Pin<P> as core::future::future::Future>::poll::hc37c0611faf80f16 https://abc/pos_bg.wasm:793516
    pos-d3f9a9396ac6ace6.wasm.<futures_util::future::future::fuse::Fuse<Fut> as core::future::future::Future>::poll::h72b80e55fb00a1cb https://abc/pos_bg.wasm:602139
    pos-d3f9a9396ac6ace6.wasm.<core::pin::Pin<P> as core::future::future::Future>::poll::hfd669a1e8159a5d8 https://abc/pos_bg.wasm:792740
    heda0e1c88f28e1f0 https://abc/pos_bg.wasm:811645
    h56f08cae7bde7347 https://abc/pos_bg.wasm:691099
    pos-d3f9a9396ac6ace6.wasm.core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut::h5c56acbbe3cb7c2c https://abc/pos_bg.wasm:814540
    h200d4a92d3afad96 https://abc/pos_bg.wasm:398182
    pos-d3f9a9396ac6ace6.wasm.<futures_util::future::poll_fn::PollFn<F> as core::future::future::Future>::poll::h4a8de8088e6c52b0 https://abc/pos_bg.wasm:804986
    h22f869721933f1be https://abc/pos_bg.wasm:389206
    hdd296834e6f5a3b8 https://abc/pos_bg.wasm:449096
    h4bc23a7d4b5e9ff7 https://abc/pos_bg.wasm:406781
    h009bf1c560b3ae81 https://abc/pos_bg.wasm:774876
    pos-d3f9a9396ac6ace6.wasm.<dyn core::ops::function::FnMut<(A,)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::haf297ebe88c09ac1 https://abc/pos_bg.wasm:676790
    __wbg_adapter_29 https://abc/pos.js:219
    real

I'm not sure what the h+hex things are... I assume the wasm line numbers are byte offsets or something.

With console-panic-error-hook I get

called `Result::unwrap()` on an `Err` value: JsValue(ReferenceError: NDEFReader is not defined
__wbg_get_imports/imports.wbg.__wbg_new_10dafc3b3f873a5a/<@https://abc/pos.js:280:21
handleError@https://abc/pos.js:239:18
__wbg_get_imports/imports.wbg.__wbg_new_10dafc3b3f873a5a@https://abc/pos.js:279:66
pos-d3f9a9396ac6ace6.wasm.pos::NDEFReader::new::h075fa8e965610c41@https://abc/pos_bg.wasm:wasm-function[793]:0x94bb0
pos-d3f9a9396ac6ace6.wasm.pos::main::{{closure}}::h898bf787e227399d@https://abc/pos_bg.wasm:wasm-function[122]:0x2a9c9
pos-d3f9a9396ac6ace6.wasm.pos::el_async::{{closure}}::{{closure}}::h0d3311f3a87a741a@https://abc/pos_bg.wasm:wasm-function[157]:0x3bc30
pos-d3f9a9396ac6ace6.wasm.<core::pin::Pin<P> as core::future::future::Future>::poll::hc37c0611faf80f16@https://abc/pos_bg.wasm:wasm-function[1789]:0xc1bac
pos-d3f9a9396ac6ace6.wasm.<futures_util::future::future::fuse::Fuse<Fut> as core::future::future::Future>::poll::h72b80e55fb00a1cb@https://abc/pos_bg.wasm:wasm-function[769]:0x9301b
pos-d3f9a9396ac6ace6.wasm.<core::pin::Pin<P> as core::future::future::Future>::poll::hfd669a1e8159a5d8@https://abc/pos_bg.wasm:wasm-function[1782]:0xc18a4
pos-d3f9a9396ac6ace6.wasm.futures_util::future::future::FutureExt::poll_unpin::heda0e1c88f28e1f0@https://abc/pos_bg.wasm:wasm-function[1963]:0xc627d
pos-d3f9a9396ac6ace6.wasm.rooting::spawn::spawn_rooted::{{closure}}::{{closure}}::{{closure}}::h56f08cae7bde7347@https://abc/pos_bg.wasm:wasm-function[1125]:0xa8b9b
pos-d3f9a9396ac6ace6.wasm.core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut::h5c56acbbe3cb7c2c@https://abc/pos_bg.wasm:wasm-function[1993]:0xc6dcc
pos-d3f9a9396ac6ace6.wasm.rooting::spawn::spawn_rooted::{{closure}}::{{closure}}::h200d4a92d3afad96@https://abc/pos_bg.wasm:wasm-function[297]:0x61366
pos-d3f9a9396ac6ace6.wasm.<futures_util::future::poll_fn::PollFn<F> as core::future::future::Future>::poll::h4a8de8088e6c52b0@https://abc/pos_bg.wasm:wasm-function[1897]:0xc487a
pos-d3f9a9396ac6ace6.wasm.rooting::spawn::spawn_rooted::{{closure}}::h22f869721933f1be@https://abc/pos_bg.wasm:wasm-function[285]:0x5f056
pos-d3f9a9396ac6ace6.wasm.wasm_bindgen_futures::task::singlethread::Task::run::hdd296834e6f5a3b8@https://abc/pos_bg.wasm:wasm-function[378]:0x6da48
pos-d3f9a9396ac6ace6.wasm.wasm_bindgen_futures::queue::QueueState::run_all::h4bc23a7d4b5e9ff7@https://abc/pos_bg.wasm:wasm-function[309]:0x634fd
pos-d3f9a9396ac6ace6.wasm.wasm_bindgen_futures::queue::Queue::new::{{closure}}::h009bf1c560b3ae81@https://abc/pos_bg.wasm:wasm-function[1634]:0xbd2dc
pos-d3f9a9396ac6ace6.wasm.<dyn core::ops::function::FnMut<(A,)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::haf297ebe88c09ac1@https://abc/pos_bg.wasm:wasm-function[1059]:0xa53b6
__wbg_adapter_29@https://abc/pos.js:219:10
real@https://abc/pos.js:200:20
VoidFunction*__wbg_get_imports/imports.wbg.__wbg_queueMicrotask_481971b0d87f3dd4@https://abc/pos.js:403:23

plus the above.

[daxpedda]

See #3698.

Browsers don't support DWARF, Chrome has some support, but requires an extension. You have to convert your DWARF into source maps, which all browsers support. There are various tools for that, I use wasm2map.

Let me know if this helps!

[andrewbaxter]

Ah thanks, that was exactly what I was missing!

[xxshady]

See #3698.

Browsers don't support DWARF, Chrome has some support, but requires an extension. You have to convert your DWARF into source maps, which all browsers support. There are various tools for that, I use wasm2map.

Let me know if this helps!

if someone is looking for a way to use it: #3698 (comment)