Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Contract & function selector outside of target contracts & selector list is running in invariant/stateful fuzz test #6166

Closed
2 tasks done
PatrickAlphaC opened this issue Oct 29, 2023 · 3 comments
Labels
T-bug Type: bug

Comments

@PatrickAlphaC
Copy link

Component

Forge

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

  • Foundry
  • Foundryup

What version of Foundry are you on?

forge 0.2.0 (dee4181 2023-10-29T00:19:39.178906000Z)

What command(s) is the bug in?

forge test --mt invariant_deltaXFollowsMath --fuzz-seed 1 -vvvvv

Operating System

macOS (Intel)

Describe the bug

I have the following setup for running stateful fuzz/invariant tests.

    function setUp() public {
        // deploy some contracts here...

        // Override the WETH address cuz it's hard-coded in the codebase and I want to mint easily
        deployCodeTo("ERC20Mock.sol:ERC20Mock", address(pool.WETH_TOKEN()));

        // do some parameter setup here...
        handler = new Handler();

        bytes4[] memory selectors = new bytes4[](2);
        selectors[0] = handler.deposit.selector;
        selectors[1] = handler.swapPoolTokenForWethBasedOnOutputWeth.selector;

        targetSelector(FuzzSelector({ addr: address(handler), selectors: selectors }));
        targetContract(address(handler));
    }

The setup clearly states there are 2 selectors to call function on:

  • swapPoolTokenForWethBasedOnOutputWeth
  • deposit

However, when I run my test, it appears to be adding odd function selectors & contracts. Here is my test:

(I have some ghost variables that I'm checking an invariant on)

    function invariant_deltaXFollowsMath() public {
        assertEq(handler.actualDeltaX(), handler.expectedDeltaX());
    }

And after running:

forge test --mt invariant_deltaXFollowsMath --fuzz-seed 1 -vvvvv

I keep breaking on this:

  [10349] Invariant::invariant_deltaXFollowsMath() 
    ├─ [2351] Handler::actualDeltaX() [staticcall]
    │   └─ ← -49999999999000000407
    ├─ [2308] Handler::expectedDeltaX() [staticcall]
    │   └─ ← -49999999999000000407
    └─ ← ()

  [2854] WETH9::burn(0x6E220FA17Fa68558Dc8884247dcD3d4D915Bba78, 115792089237316195423570985008687907853269984665640564039457584007913129639934 [1.157e77]) 
    └─ ← "ERC20InsufficientBalance(0x6E220FA17Fa68558Dc8884247dcD3d4D915Bba78, 0, 115792089237316195423570985008687907853269984665640564039457584007913129639934 [1.157e77])"

It appears to be adding the WETH9 contract to my target list, and all it's selector.

...so my question is, why?

@PatrickAlphaC PatrickAlphaC added the T-bug Type: bug label Oct 29, 2023
@gakonst gakonst added this to Foundry Oct 29, 2023
@github-project-automation github-project-automation bot moved this to Todo in Foundry Oct 29, 2023
@PatrickAlphaC
Copy link
Author

After some testing, I removed:

// Override the WETH address cuz it's hard-coded in the codebase and I want to mint easily
deployCodeTo("ERC20Mock.sol:ERC20Mock", address(pool.WETH_TOKEN()));

And replaced the hard-coded values with immutable ones, and the error went away. Looks like something fishy happens to target contracts & selectors when you use deployCodeTo to overwrite a contract address.

@grandizzy
Copy link
Collaborator

#7595 fix is available, @mattsse this one can be closed

@yan-man
Copy link

yan-man commented Apr 29, 2024

Had similar issues here, can confirm that updating to the latest version with foundryup resolved the issues with targetContract and targetSelector. Thanks!

@mds1 mds1 closed this as completed Apr 30, 2024
@jenpaff jenpaff moved this from Todo to Completed in Foundry Sep 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-bug Type: bug
Projects
Archived in project
Development

No branches or pull requests

4 participants