wasmtime / Issue #2587 Wasmtime fails to run a .wasm buil... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / Issue #2587 Wasmtime fails to run a .wasm buil...

Wasmtime GitHub notifications bot (Jan 15 2021 at 21:56):

JeremyRubin opened Issue #2587:

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

Wasmtime GitHub notifications bot (Jan 15 2021 at 21:56):

JeremyRubin labeled Issue #2587:

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

Wasmtime GitHub notifications bot (Jan 15 2021 at 22:37):

bjorn3 commented on Issue #2587:

command export 'rustsecp256k1_v0_4_0_context_no_precomp' is not a function

This is the reason. Wasmer doesn't care about this, but I believe the WASI spec doesn't allow it.

Wasmtime GitHub notifications bot (Jan 15 2021 at 22:38):

bjorn3 edited a comment on Issue #2587:

command export 'rustsecp256k1_v0_4_0_context_no_precomp' is not a function

This is the reason. Wasmer doesn't care about this, but I believe the WASI spec doesn't allow it. (not sure though)

Wasmtime GitHub notifications bot (Jan 15 2021 at 22:58):

JeremyRubin commented on Issue #2587:

Wasi doesn't allow for const pointers? (offending line in rust library https://github.com/rust-bitcoin/rust-secp256k1/blob/a24e27e94b0485a711bfa06cc331d0af7f090244/secp256k1-sys/src/lib.rs#L275)

Wasmtime GitHub notifications bot (Jan 15 2021 at 23:02):

bjorn3 commented on Issue #2587:

It does allow it, just not exported from the executable itself. It must be private.

Wasmtime GitHub notifications bot (Jan 15 2021 at 23:04):

JeremyRubin commented on Issue #2587:

Interesting -- I might be missing something, but I am not re-exporting the symbol from the executable. I am only linking against a library which does, which should be static linked?

Wasmtime GitHub notifications bot (Jan 15 2021 at 23:38):

JeremyRubin commented on Issue #2587:

@bjorn3 do you have a link to the spec you mentioned? I couldn't find a reference for it.

Wasmtime GitHub notifications bot (Jan 16 2021 at 06:34):

bjorn3 commented on Issue #2587:

It can be found at https://github.com/webassembly/wasi

Wasmtime GitHub notifications bot (Jan 17 2021 at 05:42):

JeremyRubin commented on Issue #2587:

I couldn't find anything mentioning this restriction there -- do you have a more specific link or text section to point at?

Wasmtime GitHub notifications bot (Jan 21 2021 at 01:12):

sunfishcode commented on Issue #2587:

The closest we have right now is this, though indeed there's no mention of what to do about unexpected exports.

Wasmtime's interpretation here comes from a desire to be conservative, since we expect the WASI ABI to expand and have a much richer set of things that you can do with exports in the future, and we don't want to get into a situation where a program has exports that it expects will just be ignored, where we would otherwise try to do something with them.

Are you using --export-dynamic, --export-all, or any directives to cause these symbols to be exported? I haven't tried it, but I wouldn't expect an extern "C" section to get a wasm export by default. If something like that is in play here, there may be things we can do here to help the toolchain not emit that export.

Wasmtime GitHub notifications bot (Jan 21 2021 at 17:30):

JeremyRubin commented on Issue #2587:

Yeah I think everything is under extern "C" in the secp256k1 crate; I'm not setting any additional flags on my crate.

Wasmtime GitHub notifications bot (Jan 21 2021 at 23:14):

fitzgen commented on Issue #2587:

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?

Wasmtime GitHub notifications bot (Jan 21 2021 at 23:19):

bjorn3 commented on Issue #2587:

What about only disallowing exports of unknown __wasi_* functions and globals?

Wasmtime GitHub notifications bot (Jan 22 2021 at 00:22):

sunfishcode commented on Issue #2587:

rustc is adding --export-dynamic. I've now submitted https://github.com/rust-lang/rust/pull/81255 to fix that.

A warning might be ok, however I do think it's worth looking investigating this where it does come up. Some of the cases we've seen in the past of toolchains emitting extra exports were symptoms of bigger problems -- toolchains emitting wasm files which expected their exports to be used in certain ways which don't happen in a pure WASI execution environment.

Wasmtime does have a modest allowlist for exports to ignore, however most of them were added to work around the --export-dynamic issue. Hopefully perhaps after https://github.com/rust-lang/rust/pull/81255 is in wide use we'll eventually be able to tidy that up.

Wasmtime GitHub notifications bot (Jan 22 2021 at 13:11):

tschneidereit commented on Issue #2587:

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.

Wasmtime GitHub notifications bot (Jan 22 2021 at 17:54):

fitzgen commented on Issue #2587:

--allow-unknown-exports

This sounds like a great solution to me :+1:

Wasmtime GitHub notifications bot (May 11 2021 at 19:45):

peterhuene closed Issue #2587:

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

Last updated: Dec 23 2024 at 12:05 UTC