Add fuzzing for the rust parser #9
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stusmall
force-pushed
the
add-fuzzing
branch
2 times, most recently
from
19d8f63 to
e2cfeb7
Compare
stusmall
force-pushed
the
add-fuzzing
branch
4 times, most recently
from
dd50c70 to
9439870
Compare
This adds a fuzzing task for the rust parser. This is run as release to avoid various debug assertions in the project. I've had this running on my workstation and it hasn't found anything, but it is useful to keep in CI to catch regressions. I recongize that fuzzing adds extra time to the pipeline, so I did a few things to try and minimize the impact. * First, it is a seperate, parallel workflow. Since the main build and test is a debug build and fuzz is a release build there is very little wasted work in rebuilding. * Second, I added caches for both tasks. This should help keep build time town in general. * The time the fuzzing task will run is capped at 2 minutes. This is pretty short. This was picked to not be too much longer than previous runs. This is a bit of a trade off. The longer this value is, the better the coverage. Later I will take a look at having it excercise more parser configuration options to get better coverage. At first I just wanted to try and cover the default case well.
|
Looks good to me, what do you think @Zheoni? |
|
I'm not familiar with fuzz testing. I understand that it tries random inputs to check that the parser doesn't panic, is that correct? If that's it I'm happy to merge this, caching the builds it's great too! 😄 |
|
Yup. The idea is that it will generate random input and observes coverage. It mutates the input to try and maximize coverage. It's really useful for things like this that take broad, plaintext input and parses it. It helps shake out hidden panics, logic bugs, unicode mistakes, infinite loops and various crashes. Fuzzers are generally fairly dumb and don't give you a lot of input on if the parsing was "correct", just that it didn't explode |
|
Ok, seems like a good idea to have it. Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 adds a fuzzing task for the rust parser. This is run as release to avoid various debug assertions in the project. I've had this running on my workstation and it hasn't found anything, but it is useful to keep in CI to catch regressions.
I recongize that fuzzing adds extra time to the pipeline, so I did a few things to try and minimize the impact.
Later I will take a look at having it excercise more parser configuration options to get better coverage. At first I just wanted to try and cover the default case well.