We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Panics seem to get printed decently by the interpreted runtime, but not the JIT runtime.
To reproduce, cherry-pick 149ca1a and then:
$ cargo build --release --target wasm32-unknown-unknown --manifest-path demo/impl/Cargo.toml && cargo run --manifest-path demo/caller/Cargo.toml error: proc-macro derive panicked --> demo/caller/src/main.rs:3:10 | 3 | #[derive(Demo)] | ^^^^ | = help: message: panicked at 'oh no!', src/lib.rs:5:5 $ cargo build --release --target wasm32-unknown-unknown --manifest-path demo/impl/Cargo.toml && WATT_JIT=/git/wasmtime/target/release/libwasmtime_api.so cargo run --manifest-path demo/caller/Cargo.toml fatal runtime error: failed to initiate panic, error 5 error: could not compile `watt-demo-caller`.
The text was updated successfully, but these errors were encountered:
Is this because we are panicking across an FFI boundary?
Sorry, something went wrong.
Ah yes this is a known issue with wasmtime. This is definitely related to the FFI boundary, but it's also related to JIT code generation in wasmtime.
I think the best strategy (for watt) is to ideally do something like:
That should avoid crossing any boundaries or dealing with JIT code and should work everywhere so long as wasm traps work everywhere.
Sounds good!
No branches or pull requests
Panics seem to get printed decently by the interpreted runtime, but not the JIT runtime.
To reproduce, cherry-pick 149ca1a and then:
The text was updated successfully, but these errors were encountered: