Weird behavior when computing the hash of a module

[CryptoPascal31]

Issue description

Just had a weird behavior of (hash) when computing the hash of module. The hash is not reproducible and looks like it is disturbed by the state of the REPL.

Maybe this is related to: https://github.com/kadena-io/pact/pull/1273

Steps to reproduce

In REPL:

(module my-mod G
  (defcap G() true))

(print (hash my-mod))
(print (hash my-mod))

gives:

eaWTzFZbVSOvoJa-UbwV-I3zevAZdLV1d26yr6C4_-U
b7-_hjwbZ3H5Lr5BV1ezqHtL_WFHF7dUtgTAm6_JtLs
Load successful

---

Let's try again with a slight change (just add an empty printed line between the 2 prints)

(module my-mod G
  (defcap G() true))

(print (hash my-mod))
(print "")
(print (hash my-mod))

gives:

Let's do another try 
ERM0JYQF5_YYf-s10LHUy6WnCJ3G4gIek6qd8JxUgZ0

wYo8EYDWoN3DK7WMMdTQ2jyIj8Nl1jz1fCrYK7AKWKg
Load successful

Expected Behavior

I expect the hash function to be reproducible and all the hashes shouldn't depend on externals factors.

This is not only a theoretical case. Marmalade uses as a token ID, the hash of a structure containing modrefs and may suffer from the same issue.

[rsoeldner]

@CryptoPascal31 Thank you for reporting this issue.

I'm not able to reproduce your example on master. Can you please provide more system information?

[CryptoPascal31]

Ubuntu 22.04 Pact version 4.7.0 (official binary provided by the team)

But I've also tried with my self compiled version of Pact : b160c26c6a321b18fcee48150592569a7b96cfaf.: just 1 commit before HEAD.

And I have exactly the same result for both versions when I launch pact kda_bug.repl

I attach the file. I've renamed it with a "txt" extension, since looks like GH does not allow files with a ".repl" extension. kda_bug.repl.txt

[CryptoPascal31]

A new crazy element, I've just found out.

When I change the name of the REPL file, it changes the results of the (hash) as well.

[rsoeldner]

Indeed, this is an interesting observation. It turns out that running: (module T G (defcap G () true)) inside the repl followed by (print (hash T)) twice provides the same results. If you load the file containing the same content, we get two different hash values.

We will investigate this further. Thanks for bringing this up!

[CryptoPascal31]

I confirm your observations. It seems to be ok in "interactive" mode, but fails when loading the file.

I'm glad you managed to reproduce it. => I've done my job ;-)

[rsoeldner]

@CryptoPascal31 fixed by #1278

[CryptoPascal31]

Thank you, I'll try to compile it tonight.

[CryptoPascal31]

I confirm: now it works perfectly as intended.

Whatever I'm trying to do, I get always the same and reproducible result:

• In interactive REPL
• In non interactive REPL
• On the local endpoint of my node

[CryptoPascal31]

I see that the fix has been merged => Close