No backtrace after panic! in a WASI-compiled binary

[marmistrz]

RUST_BACKTRACE has no effect on the behavior of the binary, other than hiding the note.

How to reproduce: compile the following program with the wasm32-wasi target.

fn main() {
    panic!("Hello, world!");
}

Run it with wasmtime:

[13:09:17] $ RUST_BACKTRACE=1 cargo run --bin wasmtime -- -d  bt.wasm                                
    Finished dev [unoptimized + debuginfo] target(s) in 0.06s
     Running `target/debug/wasmtime -d bt.wasm`
thread 'main' panicked at 'Hello, world!', src/main.rs:2:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error while processing main module bt.wasm: Instantiation error: Trap occurred while invoking start function: wasm trap at 0x7f1eb104e4de
[13:09:26] $ RUST_BACKTRACE=1 cargo run --bin wasmtime -- -d --env='RUST_BACKTRACE=1' bt.wasm
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/wasmtime -d --env=RUST_BACKTRACE=1 bt.wasm`
thread 'main' panicked at 'Hello, world!', src/main.rs:2:5
error while processing main module bt.wasm: Instantiation error: Trap occurred while invoking start function: wasm trap at 0x7f07b67904de

On the other hand, backtrace works when compiled for x86_64-unknown-linux-gnu:

[13:12:01] $ RUST_BACKTRACE=1 cargo run --release
    Finished release [optimized] target(s) in 0.02s
     Running `target/release/bt`
thread 'main' panicked at 'Hello, world!', src/main.rs:2:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: bt::main
   7: std::rt::lang_start::{{closure}}
   8: std::panicking::try::do_call
   9: __rust_maybe_catch_panic
  10: std::rt::lang_start_internal
  11: main
  12: __libc_start_main
  13: _start

[bjorn3]

That's because wasm doesn't provide any way to get a backtrace. On 'normal' systems, it is possible to access the stack, but wasm deliberately forbids that to make it much easier to sandbox code.

If you run wasmtime in a debugger like gdb or lldb, you can use bt to get a backtrace when you pass wasmtime the argument -d to generate debuginfo. You will probably need to set a breakpoint at the right place though.

[marmistrz]

Setting the right breakpoint may be a non-trivial task. Imagine your code has a lot of unwraps and all you know is that "some unwrap somewhere in your code or stdlib has failed" or your code has a lot to do with slices and you just find out that some indices were wrong, somewhere.

One idea I have is to add a new WASI syscall, which would answer "which function am I in now?". Alternatively, the mapping address -> function could be generated at compile time and accessed while unwinding.

[kubkon]

cc @sunfishcode @alexcrichton

[bjorn3]

Setting the right breakpoint may be a non-trivial task. Imagine your code has a lot of unwraps and all you know is that "some unwrap somewhere in your code or stdlib has failed" or your code has a lot to do with slices and you just find out that some indices were wrong, somewhere.

If you set a breakpoint at rust_begin_panic then you will break on any panic and be able to get a backtrace.

accessed while unwinding.

WASM doesnt support unwinding.

[bjorn3]

It may be nice to show a backtrace from the wasmtime side when trapping.

[alexcrichton]

Backtraces are implemented now, so closing!