Different wasm hash on different machines using "mo:base/Random"

Developers
1

Hello developers

Building the same code revision of motoko canister with “mo:base/Random” on different machines (different MacPro laptops - different production years) - gives different wasm files. File size difference is about 40 bytes of 314kb total file size.

This gives us a problem that running dfx deploy --network ic on different machines - every time there is a code upgrade…

Any thoughts?

2 Likes
2

Steps to reproduce

Actor:

import Random "mo:base/Random";

actor {
    public query func hello() : async (Text) {
        "hello"
    }
}

dfx.json record:

    "demo": {
      "main": "src/demo/main.mo",
      "type": "motoko"
    }

Calling dfx deploy demo:

➜  dfx deploy demo                                         
Deploying: demo
All canisters have already been created.
Building canisters...
Installing canisters...
Upgrading code for canister demo, with canister_id r7inp-6aaaa-aaaaa-aaabq-cai
Deployed canisters.
Execution time: 0h:00m:03s sec                                                                                                                                                                                                                                                                                             
➜  cat  .dfx/local/canisters/demo/demo.wasm | shasum -a 256
c6b19bdba6695420b2432a7242897576e6412a794fefd47241f54cdf010035fc  -

On different laptop hashcode is different

3

This probably has to do with source file paths that are embedded into the code when compiling assertions. If so, we fixed this last week, but the change may not have propagated to dfx yet.

(To verify this guess, you could try to look for, e.g., the string /base/ in the binary and see if there is a difference before it.)

2 Likes
4

@rossberg thanks for a quick reply!

Yes, there are lines like this:

aassertion failed at /Users/MY_USERNAME/.cache/dfinity/versions/0.8.1/base/Text.mo:103.19-103.35

Thanks for a quick reply.

When this fix will be available for developers?

5

We would need to make a new release of motoko (0.6.11?) which you could then use manually or wait for a following dfx release (0.8.3?) to pick up.

Is this a blocker for you?

6

No, its not a blocker…

Just wanted to know is it weeks or months…

Thanks!