crytic/echidna

[Bug-Candidate]: Set.elemAt: index out of range

Closed this issue · 16 comments

0xVolosnikov commented

Describe the issue:

[2023-09-18 13:54:06.67] [Worker 0] Crashed:

Set.elemAt: index out of range
CallStack (from HasCallStack):
  error, called at libraries/containers/containers/src/Data/Set/Internal.hs:1386:17 in containers-0.6.5.1:Data.Set.Internal

Please report it to https://github.com/crytic/echidna/issues

Code example to reproduce the issue:

https://github.com/cryptoalgebra/Algebra/blob/9fb08f3355dd84ffbd7fbb892239133f557312cf/src/periphery/contracts/test/echidna/TickLensEchidnaTest.sol

echidna ./ --contract TickLensEchidnaTest --config contracts/test/echidna/echidna.config.yml --solc-args "--evm-version paris"

Version:

Echidna 2.2.0
Slither 0.9.6

Relevant log output:

No response

ggrieco-tob commented

Hi, can you re-run using 2.2.1 just in case it was solved recently?

  • 👍1
0xVolosnikov commented

Hi, can you re-run using 2.2.1 just in case it was solved recently?

Same error
https://github.com/cryptoalgebra/Algebra/actions/runs/6221931514/job/16884846228#step:6:138

0xVolosnikov commented

Also, seems like echidna exits without error after such crash

ggrieco-tob commented

Can you re-run using coverage: true? It could be that we missed part of the initialization when coverage is disabled.

0xVolosnikov commented

Can you re-run using coverage: true? It could be that we missed part of the initialization when coverage is disabled.

Isn't working
https://github.com/cryptoalgebra/Algebra/actions/runs/6222060760/job/16885234762#step:6:125

I experimented locally, seems like this external call causes crash:
https://github.com/cryptoalgebra/Algebra/blob/9fb08f3355dd84ffbd7fbb892239133f557312cf/src/periphery/contracts/test/echidna/TickLensEchidnaTest.sol#L43

ggrieco-tob commented

Thanks for helping isolating the failure, we will investigate this crash ASAP and get back to you.

0xVolosnikov commented

I've tried to comment out everything inside of TickLens and still have this error

ggrieco-tob commented

That's interesting 🤔

0xVolosnikov commented

Hmmm, looks like immutable keyword causes problem, will do some checks

ggrieco-tob commented

oh, that looks like a regression, since we had specific code to deal with that.

  • 👍1
0xVolosnikov commented

Hmmm, looks like immutable keyword causes problem, will do some checks

Yep, error occurs when i'm trying to get something from "immutable" address of contract created in constructor

ggrieco-tob commented

I think I found the issue. Can you please re-enable contract metadata in hardhat? echidna relies on that to distinguish different contracts once they are deployed.

0xVolosnikov commented

I think I found the issue. Can you please re-enable contract metadata in hardhat? echidna relies on that to distinguish different contracts once they are deployed.

It works (immutable + metadata)

ggrieco-tob commented

That's great. We will still need to add a better error message and some documentation about it. In any case, please let us know if you have any issue, your tests looks very interesting!

  • 👍1
dwhjames commented

On the topic of “better error message and some documentation about it"…

I encountered this crash.
My issue was that I was using this strategy

with etheno and an init.json to drive the initial state of echidna. I forgot that I had made a minor edit to a contract but failed to regenerate init.json. From my guess at the underlying issue hinted at in the discussion above, the discrepancy between the stale contract deployments (within init.json) and the latest compilation artifacts triggered this issue.

ggrieco-tob commented

It seems this was already solved. Oh btw @dwhjames, etheno is obsolete with the new RPC capabilities. We should change that tutorial.