Repository navigation
Conversation
This branch has not been deployed
This file contains hidden or 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
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.
Motivation
Jazzer can bound a run by wall-clock time (
--max_duration) or by executions(
--max_executions), but both budgets are fixed up front: a campaign either getscut off while it is still finding new coverage, or keeps burning CPU long after
the corpus has saturated. The natural stopping signal - no new coverage features
for a while - has no flag in libFuzzer, so it currently has to be reimplemented
outside Jazzer by parsing the log or polling the corpus directory.
What this adds
--exit_on_time=<seconds>- exit successfully if no new coverage features arediscovered for that many seconds.
0(default) disables it. Single-processfuzzing only; rejected together with
-fork,-jobs,-mergeand-set_cover_merge.--exit_on_time_min_runs=<N>- minimum executions before--exit_on_timemayfire (default
100000), so a slow-starting target is not killed during warm-up.Both go through the usual Jazzer configuration sources and work in the standalone
driver and the JUnit integration. A native
-exit_on_timeflag takes precedenceover the Jazzer option, mirroring
-max_total_timevs--max_duration. Valuesabove
2147483647are rejected rather than silently truncated into libFuzzer'sintflags.Implementation
libFuzzer does not track when coverage last grew, so this needs a small change
there: two flags, two option fields, one timestamp updated in
RunOne, one breakcondition in
Loop(), plus flag validation. It is applied to thejazzer_libfuzzerarchive asthird_party/libfuzzer-exit-on-time.patch,following the existing
jazzer_jacocopatches inMODULE.bazel. Happy to moveit into
CodeIntelligenceTesting/llvm-project-jazzerand bump the archive taginstead if you prefer that route.
Tests
DriverTestcovers the flag translation (default and explicitmin_runs,--exit_on_time=0,min_runswithoutexit_on_time, native-flag precedence,out-of-range values).
ExitOnTimeFuzzeradds integration targets for the nativeflags, the Jazzer options, the
min_runsgate and flag precedence; it asserts itsown run duration in
fuzzerTearDownto tell an-exit_on_timeexit apart from a-max_total_timeone.Docs:
docs/arguments-and-configuration-options.mdand a "Stopping criteria"section in
README.md.