Missing frame in trap message.

[peterhuene]

In the .NET repo, there's a test (see corresponding .wat file here) that defines a host function that throws a .NET exception. The .NET API turns the exception into a C API wasm_trap_t.

This results in the following trap message on Windows:

Test error message for wasmtime dotnet unit tests.
wasm backtrace:
  0:   0xad - <unknown>!do_throw

However, on Linux and macOS, the Wasm frame is missing:

Test error message for wasmtime dotnet unit tests.

We should be able to properly capture the backtrace across all platforms and translate the wasm frames.

See bytecodealliance/wasmtime-dotnet#16 for an example of the failure (ignore the general I/O error encountered: Invalid argument (os error 22) failures as that's fixed by a Wasmtime PR under review).

cc @alexcrichton @yurydelendik

[peterhuene]

Note: I haven't investigated this at all, just noticed the discrepancy and filed the issue.

[alexcrichton]

Hm so my guess here is that the backtrace crate probably couldn't backtrace through .NET frames. Can you try confirming that with println!("{:?}", Backtrace::new()) inside of wasm_trap_new?

[peterhuene]

That would make sense. Unfortunately the CLR doesn't register JIT frames with libunwind, so I think we're probably out of luck here.

An incomplete fix would be to replace an empty trace for a trap returned from invoking a wasm_func_callback_t in func.rs, which would at least provide Wasm frames until the next CLR frame is encountered on the stack.

This quick hack does produce the expected result since there are no other .NET frames between any of the Wasm frames for this particular test case:

if let Some(trap) = out {
    let trap = trap.trap.borrow();
    if trap.trace().is_empty() {
        return Err(Trap::new(trap.to_string()));
    }
    return Err(trap.clone());
}

[alexcrichton]

That actually seems somewhat reasonable to me, it may be the case that libbacktrace can't backtrace through a number of native runtimes so having this may not be the worst thing in the world. Especially since we primarily want wasm stack frames the Rust code is guaranteed to see the same wasm frames that the CLR would have seen otherwise.

[peterhuene]

Closing this old issue as I am auditing my assigned issues.