-
Notifications
You must be signed in to change notification settings - Fork 17
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
cargo bolero repro
command?
#114
Comments
This makes cargo test likely to crash faster than the other way around, which in turn leads to faster iteration rate This is a small improvement compared to camshaft#114, but always worth it even if camshaft#114 were to land
This makes cargo test likely to crash faster than the other way around, which in turn leads to faster iteration rate This is a small improvement compared to camshaft#114, but always worth it even if camshaft#114 were to land
I usually just use It does mean that if you get a sanitizer failure, it likely won't fail inside |
Hmm so what you're saying makes sense for a development point of view when someone already knows of how However, if someone doesn't know of how bolero works, having a command to "do whatever but rerun the crash in this file" would make sense I think. For instance, if this person downloaded the crash file from a fuzzer infra like oss-fuzz (though this is pending on #98 for now, but let's assume it's already possible), and doesn't even have the Would you be open to a PR adding such a subcommand? :) |
I can't find a way to repro a single fuzzer crash from the
cargo bolero
command line.Am I missing something, or should we add such a way, eg.
cargo bolero repro [fuzzer] [crash-artifact]
?Currently, the best I found is to use
cargo test
: it compiles much faster and starts by testing the fuzzer crashes, but even it actually tests all the fuzzer crashes and corpus, and not just the one I'd like to test; which slows down the edit-compile-test cycleThe text was updated successfully, but these errors were encountered: