`OutOfGas` errors for some transactions

[0xOmarA]

Let's look at one of the failing tests from the ML test suite that fail with this error which is translated_semantic_tests/array/array_storage_index_access/test.json::0::E-

The test contract is

contract C {
    uint[] storageArray;

    function test_indices(uint256 len) public {
        while (storageArray.length < len) storageArray.push();
        while (storageArray.length > len) storageArray.pop();
        for (uint i = 0; i < len; i++) storageArray[i] = i + 1;
        for (uint i = 0; i < len; i++)
            require(storageArray[i] == i + 1, "Equality Check Failed");
    }
}

The specific step failing in this test is step 6. In this step the function is called with len = 1000. All that this test does is reset the length of the stack and then set the value of arr[i] to its index and then does an assertion. Since there's little iterations here I was expecting this test to succeed.

I saw that this specific step triggered our fallback gas mechanism in the differential testing tool. This means that when the tool attempted to get a gas estimate for this transaction it was unable to.

When I looked at the logs a little deeper I saw that the reason the gas estimation failed was the following:

ErrorResp(ErrorPayload { code: -32000, message: "The transaction consumes more than the allowed weight. needed=Weight(ref_time: 627622305184, proof_size: 64165758) allowed=Weight(ref_time: 584902658700, proof_size: 10791345283120087695) overweight_by=Weight(ref_time: 42719646484, proof_size: 0)", data: None })

So, it looks like the main reason why some of these transactions are failing is due to them being more expensive than what we allow.

Tl;Dr:

• Some of the tests failing with expected true but got false are indeed failing due to a gas related issue.
• The main reason for some of them appears to be that they consume more gas than what we allow.

The question now becomes, does the above transaction look like one that we'd expect would be able to run on our platform? If so, then I think we need to tweak the limits a little bit or perhaps the weights we assign to the various operations.

The full list of test cases failing with this error is:

• complex/create/create2_many/test.json::1::Y+
• complex/create/create_many/test.json::1::Y+
• complex/defi/UniswapV3/test_evm.json::0::E+ =0.7.6
• complex/yul_instructions/calldatasize/test_evm.json::11::Y+
• complex/yul_instructions/calldatasize/test_evm.json::11::E-
• complex/yul_instructions/calldatasize/test_evm.json::11::E+
• complex/yul_instructions/calldatasize/test_evm.json::11::Y-
• translated_semantic_tests/array/array_storage_index_access/test.json::0::E-
• translated_semantic_tests/array/array_storage_length_access/test.json::0::E-
• translated_semantic_tests/array/array_storage_push_empty_length_address/test.json::0::E-
• translated_semantic_tests/array/array_storage_push_pop/test.json::0::E-
• complex/create/create2_many/test.json::1::E+
• complex/create/create_many/test.json::1::E+