Stream: git-wasmtime

Topic: wasmtime / issue #4054 Ability to get panic reason in fun...


view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2022 at 10:20):

galibey opened issue #4054:

Feature

I would like to have the ability to somehow get a panic reason in the result of invoking WebAssembly function. Currently, it returns
wasm trap: wasm unreachable instruction execute.

Benefit

We have a Rust module that runs user-provided wasm programs during processing. If the program panicked, we would like to properly report the cause.

Implementation

I do not have an implementation plan or ideas on how to implement this.

Alternatives

In theory, we could use a panic hook to store a message to some static memory and then use it to report an error but it's quite a hacky and the hook can conflict with the user's hook.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2022 at 15:15):

alexcrichton commented on issue #4054:

Unfortunately this is not something that Wasmtime can natively provide you and is something you'd need to wrap up as an embedding. WebAssembly doesn't have any notion of a "panic cause" so what Rust-compiled-to-WebAssembly does is that it uses WASI to print the panic message and then uses the wasm unreachable instruction to raise a trap. This means that there's two channels the error information is communicated through, so your embedding will likely need to capture the WASI output and provide it with the trap that occurs, if any.

Would that work for you?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 21 2022 at 09:20):

galibey commented on issue #4054:

Yes, the WASI output capturing works for us, thanks for the hint. For WASM we will just probably make an assumption that if unreachable instruction occurred most probably there was a panic in the code.

Thanks, @alexcrichton for such a quick response.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 21 2022 at 09:20):

galibey closed issue #4054:

Feature

I would like to have the ability to somehow get a panic reason in the result of invoking WebAssembly function. Currently, it returns
wasm trap: wasm unreachable instruction execute.

Benefit

We have a Rust module that runs user-provided wasm programs during processing. If the program panicked, we would like to properly report the cause.

Implementation

I do not have an implementation plan or ideas on how to implement this.

Alternatives

In theory, we could use a panic hook to store a message to some static memory and then use it to report an error but it's quite a hacky and the hook can conflict with the user's hook.


Last updated: Nov 22 2024 at 16:03 UTC