What is the current state of backtraces in WASM?

help
1

The last update I found about this is from 2020: Is there a way to enable RUST_BACKTRACE in wasm32-unknown-unknown builds?

Is it nowadays possible to get a nice rust backtrace within WASM? Meaning a backtrace that covers my current rust function down to the rust main function. Any WASM of JS stuff that comes before or after is optional.

I tried using the trick also used in console_error_panic_hook, which is to generate a WASM stack trace instead. Unfortunately, that does not work very well:

test-83d065f45d1926f4.wasm.test::a::b::c::Type::hf1ad0209dd466543@http://localhost:8080/test-439658489e1f7e37_bg.wasm:wasm-function[492]:0xcd7fa

I can see which type the stack trace is related to, in this case a::b::c::Type. But it is missing the function, line number and column number.

As far as I understand, the reason why the standard std::backtrace::Backtrace does not work is because when compiling for WASM, the function std::env::var always returns none. But wouldn't it be possible to hardcode std::env::var("RUST_BACKTRACE") to return Ok("1".to_string()) when compiling for WASM with debug assertions enabled?

2

Wasm modules are fundamentally unable to get a backtrace on their own. You need to run javascript to get a backtrace, which gets exactly the same backtrace string as the browser console shows.

I believe some browsers are able to handle dwarf debuginfo. If you are using wasm-bindgen you will need to pass it --keep-debug to actually preserve the debuginfo in the output wasm module.

1 Like