Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add shrinking limits #297

Merged
merged 6 commits into from Feb 28, 2024
Merged

Add shrinking limits #297

merged 6 commits into from Feb 28, 2024

Conversation

Xenomega
Copy link
Member

@Xenomega Xenomega commented Feb 17, 2024

This PR adds limits for shrinking (to avoid exhaustion on very heavy-processing call sequences).

It does this by introducing a shrinkLimit value to our config. The default is 5000. It is probably a bit low for how inaccurate our value shrinking is. But it's safer for now given some projects have complex call sequences where high values could translate to quite a long amount of minutes.

This only changes the higher level shrinking loop. I added lots of comments to fuzzer_worker.go to explain it. Shrinking happens in two steps:

  • It will use 2*len(callSequence) of your shrinkLimit to first greedily remove calls. It's 2x because we first use a strategy of trying to remove a call without doing anything else (which lowers block/time number in the following blocks, because we maintain block/time delays per call). Then we try to remove them while adding the removed call's block/time delay to the previous call (which maintains block/time numbers for following blocks).
    • That should cover most cases and avoid being too greedy. This of course omits the permutations of "retaining block number or timestamp, but not both", but if the intermediate call was not necessary, retaining both should work. The only benefit we'd get is something we can add in a later PR, in a better way: a third strategy to use shrinking API to minimize the delays themselves. This seems low priority for now.
  • We use the rest of the limit exhaustively in a round-robin fashion on every call in the sequence, to try and minimize its values (the value minimization is the weak point now, but we can defer that to a later PR).

TODOs:

  • Add documentation to the wiki for this config option when it's added. We should note that shrinkLimit should always be a multiple higher of your call sequence limit to ensure you get call removal + some value minimization. Technically, it should be >=3*maxCallSequenceLen for all calls to get some removal/value minimization in the worst case, but that could change one day so I would avoid documenting it with a hard number.

… corpus results could re-record if replayed/reshrunk differently
@anishnaik anishnaik merged commit c5d7128 into master Feb 28, 2024
9 checks passed
@anishnaik anishnaik deleted the dev/add-shrinking-limits branch February 28, 2024 22:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants