This PR should close #287 . The behavior noted in that issue should not have passed through corpus call sequence replay + validation. However, there were two methods for resolving/fetching the *abi.Method associated to a CallSequenceElement/CallMessageDataAbiValues, and the logic deviated between corpus replay and fuzzer workers.
This resolved it by ensuring the CallSequenceElement.Method() function returns the CallMessageDataAbiValues.Method if it exists.
It also makes the following changes:
Deprecated CallMessageDataAbiValues.methodName in corpus.
When replaying a call sequence in the corpus, a contract would be resolved, and it's ABI would be searched through for the method by method name.
However, this does not support overloaded functions (same name, different signature). This is still read in and attempted to be used to resolve methods if newer methods fail (see next bullet point).
It should be removed after some time passes and corpuses no longer use it. It is no longer serialized. Only deserialized.
Replaced with a methodSignature field.
Added more logging to fuzzer startup to indicate where time is being spent.
Added a log for basic corpus health metrics (valid/invalid/total corpus call sequences and health %).
Reorder logging to avoid "Creating X workers" message being output after the "fuzz: elapsed[...]" message.
Note: In the future, the way I calculate active/total sequences in corpus should probably be done another way (not returned by the corpus initialize function), we can flag the corpusFile objects with an invalid (bool) field, and then add a method to loop through and "clean" them. Maybe add a --clean-corpus flag or something to remove invalid corpus items from disk :shrug:
This PR should close #287 . The behavior noted in that issue should not have passed through corpus call sequence replay + validation. However, there were two methods for resolving/fetching the
*abi.Methodassociated to aCallSequenceElement/CallMessageDataAbiValues, and the logic deviated between corpus replay and fuzzer workers.This resolved it by ensuring the
CallSequenceElement.Method()function returns theCallMessageDataAbiValues.Methodif it exists.It also makes the following changes:
CallMessageDataAbiValues.methodNamein corpus.methodSignaturefield.Note: In the future, the way I calculate active/total sequences in corpus should probably be done another way (not returned by the corpus initialize function), we can flag the
corpusFileobjects with aninvalid(bool) field, and then add a method to loop through and "clean" them. Maybe add a--clean-corpusflag or something to remove invalid corpus items from disk :shrug: