wasmtime: Wasmtime fails to run a .wasm built with rust-secp256k1, Wasmer can run it
This is an issue where wasmtime seems to read a const pointer as a function pointer, when it is actually a pointer to a constant. Wasmer does not have this issue, which suggests it’s a defect in wasmtime as opposed to the library being used.
- What are the steps to reproduce the issue?
Create a new crate bin with main.rs:
use secp256k1::*;
fn main() {
println!("Hello, world! {:?}", Secp256k1::default());
}
And Cargo.toml
[dependencies]
secp256k1 = "0.20.1"
Build in either release or debug mode for --target wasm32-wasi, and run the resulting binary using wasmtime.
- What do you expect to happen? What does actually happen? Does it panic, and if so, with which assertion?
Running under Wasmer, it will print:
Hello, world! <secp256k1 context 0x1100b0, all capabilities>
Running under Wasmtime it will print:
Error: failed to run main module `target/wasm32-wasi/debug/test-wasm-secp.wasm`
Caused by:
0: failed to instantiate "target/wasm32-wasi/debug/test-wasm-secp.wasm"
1: command export 'rustsecp256k1_v0_4_0_context_no_precomp' is not a function
- Which Wasmtime version / commit hash / branch are you using?
wasmtime 0.22.0
- If relevant, can you include some extra information about your environment? (Rust version, operating system, architecture…)
rustc 1.48.0 (7eac88abb 2020-11-16)
Distributor ID: Ubuntu Description: Ubuntu 20.04.1 LTS Release: 20.04 Codename: focal
Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 43 bits physical, 48 bits virtual CPU(s): 16 On-line CPU(s) list: 0-15 Thread(s) per core: 2 Core(s) per socket: 8 Socket(s): 1 NUMA node(s): 1 Vendor ID: AuthenticAMD CPU family: 23 Model: 1 Model name: AMD Ryzen 7 1800X Eight-Core Processor
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 15 (9 by maintainers)
Commits related to this issue
- Implement the `allow-unknown-exports` option for the run command. This commit implements the `--allow-unknown-exports` option to the CLI run command that will ignore unknown exports in a command modu... — committed to peterhuene/wasmtime by peterhuene 3 years ago
- Implement the `allow-unknown-exports` option for the run command. This commit implements the `--allow-unknown-exports` option to the CLI run command that will ignore unknown exports in a command modu... — committed to cfallin/wasmtime by peterhuene 3 years ago
- targets/wasi: remove --export-dynamic linker flag Exporting symbols seems to embed them in the WASM exports section which causes wasmtime to fail: https://github.com/bytecodealliance/wasmtime/issues/... — committed to ZauberNerd/tinygo by ZauberNerd 2 years ago
- targets/wasi: remove --export-dynamic linker flag Exporting symbols seems to embed them in the WASM exports section which causes wasmtime to fail: https://github.com/bytecodealliance/wasmtime/issues/... — committed to ZauberNerd/tinygo by ZauberNerd 2 years ago
- targets/wasi: remove --export-dynamic linker flag Exporting symbols seems to embed them in the WASM exports section which causes wasmtime to fail: https://github.com/bytecodealliance/wasmtime/issues/... — committed to ZauberNerd/tinygo by ZauberNerd 2 years ago
- targets/wasi: remove --export-dynamic linker flag Exporting symbols seems to embed them in the WASM exports section which causes wasmtime to fail: https://github.com/bytecodealliance/wasmtime/issues/... — committed to tinygo-org/tinygo by ZauberNerd 2 years ago
- targets/wasi: remove --export-dynamic linker flag Exporting symbols seems to embed them in the WASM exports section which causes wasmtime to fail: https://github.com/bytecodealliance/wasmtime/issues/... — committed to tinygo-org/tinygo by ZauberNerd 2 years ago
- targets/wasi: remove --export-dynamic linker flag Exporting symbols seems to embed them in the WASM exports section which causes wasmtime to fail: https://github.com/bytecodealliance/wasmtime/issues/... — committed to tinygo-org/tinygo by ZauberNerd 2 years ago
- targets/wasi: remove --export-dynamic linker flag Exporting symbols seems to embed them in the WASM exports section which causes wasmtime to fail: https://github.com/bytecodealliance/wasmtime/issues/... — committed to ardnew/tinygo by ZauberNerd 2 years ago
We could also consider adding a command line flag / config parameter along the lines of
--allow-unknown-exportsor perhaps--unstable-allow-unknown-exportsas an escape hatch: I do share the concern of a warning being ignored, and hard-to-fix de-facto standards being established that tie our hands later on.A bunch of wasm toolchains happen to export random extra crap. I understand our desire to be conservative here, but maybe emitting a warning, rather than refusing to execute the module, is a better balance?