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

Most upvoted comments

We could also consider adding a command line flag / config parameter along the lines of --allow-unknown-exports or perhaps --unstable-allow-unknown-exports as 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?