-
Couldn't load subscription status.
- Fork 421
Make fuzz runtime seconds not iterations #4179
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
base: main
Are you sure you want to change the base?
Conversation
|
I've assigned @wpaulino as a reviewer! |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4179 +/- ##
=======================================
Coverage 88.83% 88.83%
=======================================
Files 180 180
Lines 137504 137504
Branches 137504 137504
=======================================
+ Hits 122155 122156 +1
+ Misses 12538 12536 -2
- Partials 2811 2812 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
cbb53b6 to
3a4387d
Compare
8bfffb2 to
1ba5def
Compare
| # Because we're fuzzing relatively few iterations, the maximum possible | ||
| # compiler optimizations aren't necessary, so we turn off LTO | ||
| sed -i 's/lto = true//' Cargo.toml | ||
| sed -i 's/codegen-units = 1//' Cargo.toml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In #3916 we made some attempts of benchmarking before we removed this line. Do you have a vague number of how much the slowdown would be?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forgot about that, but its almost certainly a tiny difference in fuzzing performance, for a bit more parallelism while compiling some crates. 🤷♂️
1ba5def to
89671a5
Compare
|
Oh, weird, I guess bumping the debian version fixed the build even with 1.75, which I thought I tested....anyway, I dropped the MSRV bump for fuzzing cause it appears to be woring now. Now this just reduces the runtime to make it more consistent across jobs. |
It's failing in CI with a linking error though? |
We have some complexity in `ci-fuzz.sh` to limit each fuzzer to a rough runtime, but `honggfuzz` has a `--run-time` argument that we can simply use instead, which we do here.
This now slows us down as we run our fuzz job on a machine with more than one or two cores.
89671a5 to
fbdb5c5
Compare
|
Weird, it seems to be inconsistent, sometimes its fine, sometimes it fails. |
No description provided.