Fix EVM test scripts

[acolytec3]

The evm tests have been failing since #2405 but the npm run coverage script wasn't picking this up due to the way it was constructed and missing the error code returned by the initial call to run the tests.

TODO

• - Fix broken tests in evm/test/memory.spec.ts

[acolytec3]

@jochem-brouwer In looking at the changes from #2405 again, why do we even bother creating a memory store of anything other than 8192 bytes? I know this is ancient history but it seems like it might make it might be more efficient to just have the private store property be a buffer of 8192 bytes and then have a second length property that keeps track of the length of the "memory" for a given contract? That way, we're never having to create new buffers at all.

[codecov]

Codecov Report

Merging #2451 (4e88e1d) into master (696b36f) will decrease coverage by 0.01%.
The diff coverage is n/a.

Additional details and impacted files

Flag	Coverage Δ
block	89.51% <ø> (ø)
blockchain	90.04% <ø> (ø)
client	87.59% <ø> (ø)
common	95.76% <ø> (ø)
devp2p	91.59% <ø> (-0.03%)	⬇️
ethash	∅ <ø> (∅)
evm	79.73% <ø> (ø)
rlp	∅ <ø> (?)
statemanager	89.61% <ø> (ø)
trie	90.14% <ø> (-0.22%)	⬇️
tx	97.80% <ø> (ø)
util	84.74% <ø> (ø)
vm	85.68% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[jochem-brouwer]

We do, because every call frame needs a new buffer (so up to 1024 buffers). And we need to clear out the created buffers. If we keep "caching" this memory it means that we keep the memory allocated for the tx which used the most memory per frame (so we do not "garbage collect"). So I am not sure if this is the way the go?

[acolytec3]

As best I can tell, the code you introduced in #2404 just automatically expands the memory buffer to 8192 bytes every you read from it, if it's not already 8192 bytes. So maybe I'm not sure the difference?

[jochem-brouwer]

LGTM!