Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

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

Jump to bottom

MacOS WasmVM is "broken": Link Error: "function types incompatible: expected func of type (i64) -> (), found func of type (i32) -> () #12062

Closed
frol opened this issue Sep 6, 2024 · 5 comments · Fixed by #12096
Closed

MacOS WasmVM is "broken": Link Error: "function types incompatible: expected func of type (i64) -> (), found func of type (i32) -> () #12062

frol opened this issue Sep 6, 2024 · 5 comments · Fixed by #12096
Labels
A-contract-runtime Area: contract compilation and execution, virtual machines, etc C-bug Category: This is a bug

Comments

@frol
Copy link
Collaborator

frol commented Sep 6, 2024

Describe the bug

nearcore 2.1.1+ built for macOS cannot deploy/execute any contract:

Error: Action #1: ExecutionError("Link Error: \"function types incompatible: expected func of type `(i64) -> ()`, found func of type `(i32) -> ()`\"")

https://github.com/near/near-workspaces-rs/actions/runs/10741891187/job/29793334139

This issue blocks all the tooling upgrades (near-sandbox-js, near-sandbox-rs, near-workspaces-*, ...).

It was reported before: #11782 (comment)

To Reproduce

Pull this commit: near/near-workspaces-rs@9186ff1, and run tests (cargo test)

Expected behavior

Tests should pass.

Version (please complete the following information):

  • nearcore commit/branch: 2.1.1 (2.0.0 works fine)
  • rust version (if local)
  • docker (if using docker)
  • local (MacOS)
@frol frol added C-bug Category: This is a bug A-contract-runtime Area: contract compilation and execution, virtual machines, etc labels Sep 8, 2024
@akorchyn akorchyn mentioned this issue Sep 9, 2024
Merged
frol pushed a commit to near/near-workspaces-rs that referenced this issue Sep 10, 2024
@akorchyn
chore!: updates near-* dependencies to 0.25 (#375)
26ee55b 
Sandbox has not been updated as it's broken on Mac OS.
See near/nearcore#12062
@akorchyn
Copy link
Contributor

akorchyn commented Sep 11, 2024 •
edited
Loading

The same issue happens on the 2.2.0 release:
https://github.com/near/near-workspaces-rs/actions/runs/10813176493/job/29996604197?pr=376

@akorchyn
Copy link
Contributor

I have made some initial investigation and tried to determine the failure point.
Using some Github actions and binary search I have located the next commit:
872ac5c

I have adjusted to compile the nearcore sandbox (as some versions are not available on s3) and run tests:

This commit fails on the CI
https://github.com/near/near-workspaces-rs/actions/runs/10835306324/job/30066537415 - fails
The commit before passes on the CI
https://github.com/near/near-workspaces-rs/actions/runs/10835654098/job/30067647491

@akorchyn
Copy link
Contributor

The issue is reproducible on any OS using:
cargo t -p near-vm-runner --features wasmtime_vm,near_vm

@akorchyn
Copy link
Contributor

Weird, but it's only reproducible if you remove engine from WasmtimeVM and recreate it each time. Otherwise, test passes :(
As I did here for example: master...akorchyn:nearcore:test-fix

@akorchyn
Copy link
Contributor

If the engine is new, it won't work. Potentially the issue is within: precompile and then prepare and run on another engine.

To reproduce the issue just use a new engine before the linker.instantiate()
It's a bit weird as the documentation says that if you have the same compatibility hash it should work.

Though, it doesn't

Returns a [std::hash::Hash] that can be used to check precompiled WebAssembly compatibility.

The outputs of [Engine::precompile_module] and [Engine::precompile_component]
are compatible with a different [Engine] instance only if the two engines use
compatible [Config]s. If this Hash matches between two [Engine]s then binaries
from one are guaranteed to deserialize in the other.

@akorchyn akorchyn mentioned this issue Sep 16, 2024
Merged
github-merge-queue bot pushed a commit that referenced this issue Sep 16, 2024
@akorchyn
bugfix: wasmtime: instantiating function type incompatibility (#12096)
773aae7 
Resolves: #12062 

This PR resolves the issue with the wasmtime function type
incompatibility.
To understand the issue, I highly recommend my investigation comments on
the issue itself: #12062

To be honest, I'm not sure it's a proper fix as I guess the root cause
of the issue is somewhere outside of the file that leads to running
under different engines/settings, leading to instantiating failures.
It's a bit weird that the WasmtimeVM instance and Module instance could
be different somehow as wasmtime::Engine is an arc wrapper. And module
seems to clone it inside which should be still the same instance.

I could reproduce the issue only by tweaking the code manually by
recreating an engine before the linking. It means that something more
complex happens and we need a test on that

But this fix resolves an issue reported by #12062:
https://github.com/near/near-workspaces-rs/actions/runs/10835958697/job/30200440749


CC @race-of-sloths
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-contract-runtime Area: contract compilation and execution, virtual machines, etc C-bug Category: This is a bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

bugfix: wasmtime: instantiating function type incompatibility akorchyn/nearcore
2 participants
@frol @akorchyn