Fix corpus call method resolution bug, improve startup logging #308
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 aCallSequenceElement
/CallMessageDataAbiValues
, and the logic deviated between corpus replay and fuzzer workers.This resolved it by ensuring the
CallSequenceElement.Method()
function returns theCallMessageDataAbiValues.Method
if it exists.It also makes the following changes:
CallMessageDataAbiValues.methodName
in corpus.methodSignature
field.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 aninvalid
(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 🤷