bug(forge): createx tx fails due to wrong gas fixed limit estimation

[area]

Component

Forge

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

• Foundry
• Foundryup

What version of Foundry are you on?

forge Version: 1.4.1-stable

What version of Foundryup are you on?

foundryup: 1.3.0

What command(s) is the bug in?

forge script

Operating System

Linux

Describe the bug

I have a script to deploy my contracts that succeeds on 1.3.6 but fails on 1.4.x when using forge script. The simulation succeeds, but then the first transaction is attempted to be sent with a preposterous gas limit (over 1 billion), which obviously fails:

 Error: Failed to send transaction

Context:
- deserialization error: missing field `code` at line 1 column 114
{"jsonrpc":"2.0","error":{"message":"Transaction gas limit is 1056754851 and exceeds block gas limit of 30000000"},"id":2}    

I have tried and failed to come up with a MWE, so apologies for that, and I can't currently share the relevant repository. I will continue to try and find a MWE. However:

• The telegram suggested this commit could be responsible, and that seems likely - nightly-cb9f413cf84c862c682e15176bbc06f3293822a7 successfully runs the script, but nightly-5dbd958d16125937bc761aece6cf3e69883ebdb3 does not.
• Further to that, in the broadcast artifacts, isFixedGasLimit is true when the preposterous gas limit is attempted, but is false when a sane gas limit is present.
• While removing components from the script to try and find the MWE, I ended up in a situation where I had an 'if' statement of the form

        if (a != b) {
            revert("Fail");
        }

In that state, the script failed with the above gas limit error message. If the revert was replaced with a console.log, the script failed. If the revert was removed entirely, but the 'if' statement remained, the script succeeded (but in that case, maybe the compiler is smart enough to remove the conditional entirely?). I also (reliably) saw this succeed:

        if (a != b) {
            uint256 x = 0;
            x++;
        }

But this fail:

        uint x = 0;
        if (a != b) {
            x++;
        }

• Another thing that I think could be relevant from my limited understanding of the (possibly) relevant PR is that the deployments are being performed using the CREATE3 pattern in CreateX, which uses the CREATE2 opcode under-the-hood.

I will update this issue should I come up with a minimal reproduction of the bug.

[grandizzy]

thanks @area I tried several combinations too but wasn't able to repro either, this most probably happens when 2 successive create3 txes happens (and the gas limit tracker of 1st doesn't reset), maybe you could look into such sequence in your scripts

[area]

I tried the #12155 branch and it did not fix the issue for me. However, I now have a standalone reproduction that is hopefully sufficient for demonstrating the issue. This includes a final if statement, that if commented out, causes the bug to not appear.

[grandizzy]

hey @area had time to look into this thoroughly, the reason is that the script is compiled with via_ir = true so our logic to determine if dynamic gas (that is a GAS opcode followed by a CALL opcode) doesn't apply anymore because the sequence is turned into

GAS
SWAP4
PUSH20
PUSH1
SWAP6
CALL

The initial PR worked but is not the proper fix, will look into making such and include in v1.4.4