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.

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

Post processing of generated Wasm failed with rustc 1.70.0-nightly #1058

Closed
ashutoshvarma opened this issue Mar 31, 2023 · 15 comments
Closed

Comments

@ashutoshvarma
Copy link
Contributor

Summary
Building contracts with rustc 1.70.0-nightly failed due to error in post processing step due to error in parity-wasm while loading the wasm module.

https://substrate.stackexchange.com/questions/7881/error-loading-of-original-wasm-failed

 [2/5] Post processing wasm file
ERROR: Loading of original wasm failed

Caused by:
    0: Loading of wasm module at '/home/oreki/Projects/meta-tx/target/ink/registry/wasm32-unknown-unknown/release/registry.wasm' failed
    1: Unknown opcode 192

parity_wasm::deserialize_file(path).context(format!(
"Loading of wasm module at '{}' failed",
path.display(),
))

Reproduce
Update the nightly to v1.70.0 and build flipper example with cargo +nightly contract build

@peetzweg
Copy link
Member

peetzweg commented Apr 3, 2023

Just had the same issue. If you are blocked by this, switch to the stable toolchain instead of nightly.
Afaik cargo contract is not aiming to always work with nightly and stable should be used from now on.

rustup default stable

@ashutoshvarma
Copy link
Contributor Author

ashutoshvarma commented Apr 3, 2023

I'm aware of the workarounds,

  1. Switch to stable rustc
  2. If using openbrush (using nightly is required for openbrush still), use nightly v1.69.0 v1.67.1 or older.

Afaik cargo contract is not aiming to always work with nightly and stable should be used from now on.

I understand that with ink! v4 nightly toolchain is no longer required and stable is recommended but openbrush which majority of ink! ecosystem is using still depends on nightly, so this issue might help guys who are likely to struggle with newer nightly toolchain.
Also, I don't think it is a cargo-contract specific problem, it is more an issue in parity-wasm which although deprecated, is still used inside cargo-contract. That adds more reason to replace parity-wasm with something that is not deprecated (like wasm-opt/binaryen tools).

@ganesh1997oli
Copy link

I am still facing issue even though I change nightly v1.68 or v1.69 or v1.70 it doesn't work.

@ashutoshvarma
Copy link
Contributor Author

@ganesh1233456 try with nightly rustc 1.67.1 (d5a82bbd2 2023-02-07), it worked for me.

@blairmunroakusa
Copy link

@ashutoshvarma ... I am having a difficult time figuring out how to install and switch to rustc 1.67.1 (d5a82bbd2 2023-02-07). Could you please share how you accomplish this?

@ganesh1997oli
Copy link

@blairmunroakusa my system has rust installed already then I use rustup default <version> to switch to specific version. But the things is my issue completely not solved, sometimes it works and sometime not work.

@yahortsaryk
Copy link

yahortsaryk commented Apr 8, 2023

@blairmunroakusa my system has rust installed already then I use rustup default <version> to switch to specific version. But the things is my issue completely not solved, sometimes it works and sometime not work.

I have the same issue. I'm compiling my source code (ink! v4.1.0) using rustc 1.67.1 and enabled +nigthly flag. Sometimes the build finishes successfully, and sometimes I'm getting Unknown opcode 192 error on the post-processing wasm file step. It really happens randomly.

Please, let us know what can be the reason for this non-deterministic behavior. It is really annoying issue for CI/CD processes

@yahortsaryk
Copy link

I'm not sure what's happening on my local environment, I suggest anybody who is struggling with this build problem try to refer the Installation using Docker Image section and compile your contracts using official docker images. It works for me

@blairmunroakusa
Copy link

blairmunroakusa commented Apr 9, 2023

Ok @yahortsaryk @ganesh1233456 ...got it figured out on my system:

First:

rustup install nightly-2023-02-07-aarch64-apple-darwin
rustup component add rust-src --toolchain nightly-2023-02-07-aarch64-apple-darwin

Then:

cargo +nightly-2023-02-07 contract build

Still running updated nightly rustc as default:
image

Thank you @ashutoshvarma

@AgentPoles
Copy link

AgentPoles commented Apr 10, 2023

Thanks a lots @blairmunroakusa, worked for me! Just to mention for anyone trying this method, if you have "rlib" crate-types in your project, you might wanna skip those and apply to actual contracts: "cdylib" crate-types

@blairmunroakusa
Copy link

Now I'm having same opcode throw when trying to run substrate-contracts-node.

@ganesh1997oli
Copy link

yes @blairmunroakusa exactly there is issue in substrate-contracts-node as well. Alternatively, I tend to download and use binary and it works.

Screenshot 2023-04-11 at 11 31 52

@blairmunroakusa
Copy link

Thank you @ganesh1233456 , this worked for me.

@upendra-eth
Copy link

upendra-eth commented Apr 20, 2023

Ok @yahortsaryk @ganesh1233456 ...got it figured out on my system:

First:

rustup install nightly-2023-02-07-aarch64-apple-darwin
rustup component add rust-src --toolchain nightly-2023-02-07-aarch64-apple-darwin

Then:

cargo +nightly-2023-02-07 contract build

Still running updated nightly rustc as default: image

Thank you @ashutoshvarma

thanks, it worked but it's not deploying on the blockchain , maybe because its using Bineryen

@ascjones
Copy link
Member

ascjones commented Jun 5, 2023

Rust 1.70 is producing the sign-ext opcode which is neither compatible with parity-wasm which is what produces the error in cargo-contract, nor in pallet-contracts itself.

Ideally we would disable that feature but it appears that this does not work, see this upstream issue: rust-lang/rust#109807.

I will close this issue as a duplicate of #1139, where we can continue any discussion for the resolution of this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants