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

Weird behavior when computing the hash of a module #1277

Closed
CryptoPascal31 opened this issue Aug 14, 2023 · 9 comments
Closed

Weird behavior when computing the hash of a module #1277

CryptoPascal31 opened this issue Aug 14, 2023 · 9 comments

Comments

@CryptoPascal31
Copy link
Contributor

CryptoPascal31 commented Aug 14, 2023

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: #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
Copy link
Member

@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
Copy link
Contributor Author

CryptoPascal31 commented Aug 14, 2023

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 : b160c26.: 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
Copy link
Contributor Author

CryptoPascal31 commented Aug 14, 2023

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

@CryptoPascal31 fixed by #1278

@CryptoPascal31
Copy link
Contributor Author

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

@CryptoPascal31
Copy link
Contributor Author

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
Copy link
Contributor Author

I see that the fix has been merged => Close

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

2 participants