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.