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

Dynamic arrays are not allocated properly in storage, overlap with following variables #2820

Closed
haltman-at opened this issue Apr 21, 2022 · 1 comment · Fixed by #2821
Closed

Comments

@haltman-at
Copy link

Version Information

  • vyper Version (output of vyper --version): 0.3.2
  • OS: Release Linux Mint 20.3 Una 64-bit
  • Python Version (output of python --version): Python 3.8.10

What's your issue about?

Dynamic arrays are not being allocated properly in storage. Specifically, whatever variable comes after a dynamic array will not, in fact, be placed after it, but rather will overlap with the final storage slot of the dynamic array. This is obviously really bad!

For example, consider the following contract:

arr: DynArray[uint256[2], 3]
interfere: uint256

@external
def run() -> uint256:
    self.arr.append([1, 2])
    self.arr.append([3, 4])
    self.arr.append([5, 6])
    self.interfere = 7
    return self.arr[2][1]

If you deploy this contract and then run the run method, then the storage afterward should look like this:

  0000000000000000000000000000000000000000000000000000000000000003
  0000000000000000000000000000000000000000000000000000000000000001
  0000000000000000000000000000000000000000000000000000000000000002
  0000000000000000000000000000000000000000000000000000000000000003
  0000000000000000000000000000000000000000000000000000000000000004
  0000000000000000000000000000000000000000000000000000000000000005
  0000000000000000000000000000000000000000000000000000000000000006
  0000000000000000000000000000000000000000000000000000000000000007

Instead, we have this:

  0000000000000000000000000000000000000000000000000000000000000003
  0000000000000000000000000000000000000000000000000000000000000001
  0000000000000000000000000000000000000000000000000000000000000002
  0000000000000000000000000000000000000000000000000000000000000003
  0000000000000000000000000000000000000000000000000000000000000004
  0000000000000000000000000000000000000000000000000000000000000005
  0000000000000000000000000000000000000000000000000000000000000007

Moreover, if (again, after a clean deploy) you do it as a call rather than as a transaction, you'll see that you get a return value of 7, rather than 6, as you should.

I'm hoping there can be some sort of hotfix for this, for obvious reasons! Thank you!

@charles-cooper
Copy link
Member

Looking into 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

Successfully merging a pull request may close this issue.

2 participants