Fuzz Test Failure in Counter.t.sol on zkSync with Foundry in Windows/WSL

[Vasiliy Gualoto]

Component

Forge

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

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.0.2 (624cd93 2024-08-09T00:23:41.549447527Z)

What command(s) is the bug in?

forge test --zksync

Operating System

Windows

Describe the bug

When creating a new project and running the default test script on Counter.t.sol using the zkSync network with Foundry, the fuzz test fails due to an unexpected counterexample. This issue occurs specifically on Windows 11 using WSL (both Ubuntu 20.04 and 24.04). The same test script runs successfully on macOS.

Steps to Reproduce:

• Create a new project in Foundry.

• Use the default test script Counter.t.sol.

• Run the fuzz test using the command: forge test --zksync -vvvv.

• Observe the test failure with the following error:

test --zksync -vvvv
[⠊] Compiling...
No files changed, compilation skipped
[⠃] Using zksolc-1.5.1
[⠊] Compiling (zksync)
No files changed, compilation skipped
proptest: Aborting shrinking after the PROPTEST_MAX_SHRINK_ITERS environment variable or ProptestConfig.max_shrink_iters iterations (set 0 to a large(r) value to shrink more; current configuration: 0 iterations)

Ran 2 tests for test/Counter.t.sol:CounterTest
[FAIL. Reason: EvmError: Revert; counterexample: calldata=0x240f4157ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff args=[115792089237316195423570985008687907853269984665640564039457584007913129639935 [1.157e77]]] testFuzz_SetNumber(uint256) (runs: 0, μ: 0, ~: 0)
Traces:
  [37780] 0xbB19D84ecdC99Fe7C212B82f9B0B15EE6e852834::setUp()
    ├─ [0] → new <unknown>@0xc2E5d2d6D9d77E5C254DD4eE76b365143A188092
    │   └─ ← [Return] 32 bytes of code
    ├─ [0] 0xc2E5d2d6D9d77E5C254DD4eE76b365143A188092::setNumber(0)
    │   └─ ← [Return]
    └─ ← [Stop]

  [214] 0xbB19D84ecdC99Fe7C212B82f9B0B15EE6e852834::testFuzz_SetNumber(115792089237316195423570985008687907853269984665640564039457584007913129639935 [1.157e77])
    └─ ← [Revert] EvmError: Revert

[PASS] test_Increment() (gas: 8675)
Traces:
  [8675] 0xbB19D84ecdC99Fe7C212B82f9B0B15EE6e852834::test_Increment()
    ├─ [0] 0xc2E5d2d6D9d77E5C254DD4eE76b365143A188092::increment()
    │   └─ ← [Return]
    ├─ [0] 0xc2E5d2d6D9d77E5C254DD4eE76b365143A188092::number() [staticcall]
    │   └─ ← [Return] 0x0000000000000000000000000000000000000000000000000000000000000001
    ├─ [0] VM::assertEq(1, 1) [staticcall]
    │   └─ ← [Return]
    └─ ← [Stop]

Suite result: FAILED. 1 passed; 1 failed; 0 skipped; finished in 19.88ms (7.86ms CPU time)

Ran 1 test suite in 701.51ms (19.88ms CPU time): 1 tests passed, 1 failed, 0 skipped (2 total tests)

Failing tests:
Encountered 1 failing test in test/Counter.t.sol:CounterTest
[FAIL. Reason: EvmError: Revert; counterexample: calldata=0x240f4157ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff args=[115792089237316195423570985008687907853269984665640564039457584007913129639935 [1.157e77]]] testFuzz_SetNumber(uint256) (runs: 0, μ: 0, ~: 0)

Encountered a total of 1 failing tests, 1 tests succeeded

Expected Behavior:
The fuzz test should run without errors, as it does on macOS and regular Foundry without zkSync.

Actual Behavior:
The fuzz test fails due to an EvmError: Revert, identifying a counterexample that causes the test to abort.

Test Script:

function testFuzz_SetNumber(uint256 x) public {
    counter.setNumber(x);
    assertEq(counter.number(), x);
}

Additional Context:

This issue is specific to Windows 11 with WSL (Ubuntu 20.04 and 24.04).
The same command runs without issues on macOS.
The failure seems linked to the zkSync integration in Foundry.
System Information:

Operating System: Windows 11
WSL Versions: Ubuntu 20.04, Ubuntu 24.04
zkSync Version: zksolc-1.5.1

[犭苗]

我也是这样

[Federico Rodríguez]

@cromewar could you try building from main or using one of the later releases: https://github.com/matter-labs/foundry-zksync/releases/tag/nightly-1cf88dc1e3118dadefdc823526b9f1966e5b98b5
We addressed an issue that was causing problems similar to yours so it might be related.

[Dustin Brickwood]

Closing due to staleness.