eth-brownie / brownie

A Python-based development and testing framework for smart contracts targeting the Ethereum Virtual Machine.

Home Page:https://eth-brownie.readthedocs.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Possible memory leak

oswaldoleal opened this issue · comments

Environment information

  • brownie Version: 1.19.1
  • ganache Version: 7.5.0
  • ganache-cli Version: 0.6.0
  • ganache-cli Version: 0.6.0
  • solc Version: 0.8.14+commit.80d49f37.Linux.g++
  • Python Version: 3.9.9
  • OS: linux (Ubuntu 22.04.1 LTS x86_64)

For a bit of context, I have a project with a pretty extensive tests and for a while now I have noted that the tests are taking way too long to complete and they use too much memory. It seems to me like the is no consistent behavior on how the code runs using the different available commands (brownie console, brownie test, brownie run).

In my specific situation this is how I noticed it
I picked the biggest test I have and first ran it using brownie test path/to/the/test.py, using this command I saw that midway through the test the memory usage shoot up 11+ GB and it took around 5 mins to complete. The next thing I tried was to run the test function from inside the brownie console, doing it this way the same test took around 16 secs to complete and the peak memory usage was around 500 MB. Lastly I tried running the test file as a script using the brownie run path/to/the/script.py, the behavior that I saw running this command was similar to that of running the brownie test command, ~5 mins run time and incredibly high memory usage, but this time I noticed something else, since run command shows the submitted transactions and its state (and the test command doesn't) I was able to see that there a significant slow down when a transaction is reverted and it is accompanied by a huge increase in memory usage.

Those reverting transactions are expected and the testing code looks like this:

with pytest.raises(exceptions.VirtualMachineError):
    contract.revertingTransaction({'from': '0x134656...'})

As a final note I have to say that the running the test with any of the three ways noted above returns a successful tests, all assertions are met

And now I ask, is this a problem you are aware of? if so, do you have possible solutions? if not, what else can I do to help diagnose the issue?

Small addition, running the same test using brownie test path/to/the/test.py under the same environment but using an M1 MacBook with 8 GB of ram, the issue is less apparent but still there, it takes 2 mins 40 secs (about have of the linux machine that has a ryzen 5 5500U and 16 GB of ram) but it uses significantly less memory at 2.4 GB