anvil: EVM error MemoryLimitOOG

[ryanio]

Component

Anvil

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (f9da73d 2024-03-23T00:16:29.636127000Z)

What command(s) is the bug in?

anvil

Operating System

macOS (Apple Silicon)

Describe the bug

I opened #7478 that I hoped would fix this issue for me, but even when running a locally built anvil version with a much higher memory limit (128 mb -> 2 or 4gb) I'm still getting EVM error MemoryLimitOOG so I feel like this a bug more internal to the evm or its setup.

For reproduction:

1. Run anvil with:
   anvil --host 0.0.0.0 --fork-url=$ETHEREUM_RPC_URL --chain-id=1
2. Download the requests to anvil: Request_Body_03-25-2024-10-55-20.folder.zip
3. Unzip the folder and cd into it with a terminal. Run:

   while IFS= read -r file; do
       curl -X POST -H "Content-Type: application/json" -d @"$file" http://localhost:8545
   done < <(ls | sort -V)
   

4. Observe that the last lines returned are:

   {"jsonrpc":"2.0","id":51,"error":{"code":-32603,"message":"EVM error MemoryLimitOOG"}} 
   {"jsonrpc":"2.0","id":975548868,"result":null}
   

To summarize what the requests are doing, they are from our integration test suite that sets up an address with ETH and WETH, mints some items and grants approvals, then uses SeaportRouter to fulfill. This problem is not inherent to SeaportRouter since we are running into the same MemoryLimitOOG testing other Seaport contracts.

[samlaf]

Also running into this issue. Definitely seems to be an issue with the latest release, as I pinned an older version from 3 weeks ago of anvil and it doesn't have this issue.
Layr-Labs/incredible-squaring-avs#34

[mattsse]

@rakita does this ring any bells?

any recent changes that concerns this error?

[mattsse]

@ryanio couldn't reproduce, script stops after

{"jsonrpc":"2.0","id":47,"error":{"code":-32602,"message":"No Signer available"}}{"jsonrpc":"2.0","id":48,"result":{"hash":"0x654e8c7f6430edc50f1c4167f434a2362a78cc1f6fa5f69dee8348c91931d4ce","parentHash":"0xd174b29125e3561bbd37c59c25da6a9aa2a3f51f6ba7f7b8629c525ac0f1056a","sha3Uncles":"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347","miner":"0x0000000000000000000000000000000000000000","stateRoot":"0x0000000000000000000000000000000000000000000000000000000000000000","transactionsRoot":"0xe5df98398173fb61b807cfd2eafe094329b78d56a6d632af6b1ecc0032be85af","receiptsRoot":"0xb0d9dfa7882005af5e0a0a3036d59add41292122c2a705cdb273e3624b6ab8f8","logsBloom":"0x00000000040000000000000000000000000000000000080000000000000000000000000000000000000000000000000002000000080000000000000020000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400010000000000000000000000000000000000000000000000000000000000040000000000020000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000","difficulty":"0x0","number":"0x1297011","gasLimit":"0x1c9c380","gasUsed":"0xc9ca","timestamp":"0x6601b978","totalDifficulty":"0xc70d815d562d3cfa955","extraData":"0x","mixHash":"0x0000000000000000000000000000000000000000000000000000000000000000","nonce":"0x0000000000000000","baseFeePerGas":"0x6cb979c75","uncles":[],"transactions":["0x7f280497d75ff6897434f9129098bcebe84e06f4928cfcfcd99b60dc2daeb847"],"size":"0x29e"}}{"jsonrpc":"2.0","id":49,"result":"0x1"}{"jsonrpc":"2.0","id":50,"result":"0x1"}{"jsonrpc":"2.0","id":51,"error":{"code":3,"message":"execution reverted: revert: ERC721: invalid token ID","data":"0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000184552433732313a20696e76616c696420746f6b656e2049440000000000000000"}}{"jsonrpc":"2.0","id":975548868,"result":null}

[rakita]

@rakita does this ring any bells?

any recent changes that concerns this error?

Shouldn't be any. Logic is simple, and it was not changed in a while.

[ryanio]

@mattsse sorry about that, will try to work on another repro case, this one seems pretty fragile

@samlaf do you have any simple repro case you can share?

[mattsse]

what changed recently is the default hardfork with cancun, could be unrelated though, but perhaps you try --hardfork shanghai just to rule that out

[ryanio]

yeah, unfortunately need cancun for tstore for seaport 1.6 (it won't use tstore when deployed on networks without it, but since it was deployed on mainnet after cancun it will be using it)

[samlaf]

@ryanio def not simple, but I do have a repro setup.
@mattsse, I tried with --hardfork shanghai and it didn't help.

Repro:

1. clone https://github.com/Layr-Labs/incredible-squaring-avs, make sure to install the dependencies
2. Run make start-anvil-chain-with-el-and-avs-deployed
3. In a separate window, run make start-operator

This will work as I've pinned foundry to nightly-de33b6af53005037b463318d2628b5cfcaf39916
To repro, run foundryup, comment the docker line, and uncomment the anvil line just above it. Also add the --hardfork shanghai flag and rerun steps 2 and 3 above to show that it fails with error

[2024-03-27 10:59:08.548 PDT] FATAL (logging/zap_logger.go:61) Error depositing into strategy {"err":"EVM error MemoryLimitOOG"}

[klkvr]

@mattsse bisected and it seems to be caused by 9fde758

[mattsse]

hmm, that's odd.

do we know which rpc calls are failing? I hope it is eth_estimate? because then I think I have an idea.

with the revm native conversion we no longer end up with OutOfgas result:

9fde758#diff-a0d1dbafd7eaf82b3fd4d30722d2c7e369394883a704e8b41554d0a31b43629fL30

so these are no longer caught:

foundry/crates/anvil/src/eth/api.rs

Lines 2350 to 2361 in 9881e7d

	InstructionResult::Revert |
	InstructionResult::OutOfGas |
	InstructionResult::OutOfFunds |
	// we're also checking for InvalidFEOpcode here because this can be used to trigger an error <https://github.com/foundry-rs/foundry/issues/6138> common usage in openzeppelin <https://github.com/OpenZeppelin/openzeppelin-contracts/blob/94697be8a3f0dfcd95dfb13ffbd39b5973f5c65d/contracts/metatx/ERC2771Forwarder.sol#L360-L367>
	InstructionResult::InvalidFEOpcode => {
	lowest_gas_limit = mid_gas_limit;
	}
	// The tx failed for some other reason.
	reason => {
	warn!(target: "node", "estimation failed due to {:?}", reason);
	return Err(BlockchainError::EvmError(reason))
	}

and return an error instead if memoryOOG

here:

foundry/crates/anvil/src/eth/backend/mem/mod.rs

Line 1134 in 9881e7d

ExecutionResult::Halt { reason, gas_used } => (reason.into(), gas_used, None),

because this now uses revm's conversion:

https://github.com/bluealloy/revm/blob/c3107ec3acf79119016acac203b1c2437005a90e/crates/interpreter/src/instruction_result.rs#L65-L71

@samlaf could you confirm that the failing calls are eth_estimate?