Post processing of generated Wasm failed with rustc 1.70.0-nightly

[ashutoshvarma]

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

https://github.com/paritytech/cargo-contract/blob/1d28f4ef3863e1f6a438f59890545eb87e1e863a/crates/build/src/lib.rs#L468-L471

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

[peetzweg]

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]

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]

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

[ashutoshvarma]

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

[blairmunroakusa]

@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]

@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]

@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]

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]

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:

Thank you @ashutoshvarma

[AgentPoles]

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]

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

[ganesh1997oli]

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

[blairmunroakusa]

Thank you @ganesh1233456 , this worked for me.

[upendra-eth]

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:

Thank you @ashutoshvarma

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

[ascjones]

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.