[Bug-Candidate]: Sequences from corpus do not adhere to time/block delay settings

[rappie]

Describe the issue:

Sequences that have long time delays are still used, even in cases where I've changed the settings to this:

maxTimeDelay: 1
maxBlockDelay: 1

Code example to reproduce the issue:

1. Run Echidna normally
2. Have an invariant break using long time/block delays that would not break with short delays
3. Store corpus
4. Lower time delays in config
5. Run Echidna with new config
6. Invariant still breaks even though the new config would not allow the sequences used to break it

Version:

Echidna 2.2.3

Relevant log output:

No response

[ggrieco-tob]

This is expected, the echidna configuration will not enforce anything in the corpus. I think the same will happen with the max ether sent. Perhaps this can be a feature of fuzz-utils, where a certain corpus is "modified" to do X instead of Y. @rappie Can you please start a discussion there for this feature?

[rappie]

Personally I would expect the config settings to be overruling everything, so I would consider this a bug or at least unexpected behaviour. I've had similar issues in the past where i had to discard my corpus because I needed to blacklist certain functions (that were still in the corpus).

Is there no possibility check sequences from the corpus against the allowed settings before they are executed?

[mds1]

@rappie What is your expected behavior here? My intuition is to agree with @ggrieco-tob that the corpus should still run with its original config.

Are you suggesting to modify the corpus based on the new config, or to skip sequences that don't have compatible configs? Modifying the corpus seems like it may cause sequences to unexpectedly pass only due to the config change, but skipping non-applicable ones seems ok. Based on crytic/fuzz-utils#51 I think you are suggesting modification? Interested in better understanding your use case

[rappie]

The behaviour I expect is that the config leads, meaning sequences in the corpus which are illegal according to the current config should be skipped.

I'm not a fan of rewriting the corpus, this seems error prone and could lead to unpredictable/unwanted behaviour.

My reasoning behind this:

• The config describes how the fuzzer works and which actions are allowed
• The corpus is a repository of interesting sequences to help the fuzzer discover new coverage in its current run