Stream: git-wasmtime

Topic: wasmtime / Issue #1845 Missing frame in trap message.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 08 2020 at 20:08):

peterhuene opened Issue #1845:

In the .NET repo, there's a test 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

view this post on Zulip Wasmtime GitHub notifications bot (Jun 08 2020 at 20:08):

peterhuene labeled Issue #1845:

In the .NET repo, there's a test 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

view this post on Zulip Wasmtime GitHub notifications bot (Jun 08 2020 at 20:10):

peterhuene commented on Issue #1845:

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

view this post on Zulip Wasmtime GitHub notifications bot (Jun 08 2020 at 20:11):

peterhuene edited Issue #1845:

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

view this post on Zulip Wasmtime GitHub notifications bot (Jun 08 2020 at 20:12):

peterhuene assigned Issue #1845:

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

view this post on Zulip Wasmtime GitHub notifications bot (Jun 09 2020 at 13:57):

alexcrichton commented on Issue #1845:

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?

view this post on Zulip Wasmtime GitHub notifications bot (Jun 10 2020 at 01:09):

peterhuene commented on Issue #1845:

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());
}

view this post on Zulip Wasmtime GitHub notifications bot (Jun 10 2020 at 14:39):

alexcrichton commented on Issue #1845:

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.

Last updated: Dec 23 2024 at 12:05 UTC