path in the code under test, then that mutation is saved to the corpus for
future variations.
-LibFuzzer will work fine without any initial seeds, but will be less
-efficient. In particular, if the library under test accepts complex,
-structured inputs then starting from a varied corpus is very important.
+LibFuzzer will work without any initial seeds, but will be less
+efficient if the library under test accepts complex,
+structured inputs.
The corpus can also act as a sanity/regression check, to confirm that the
fuzzing entrypoint still works and that all of the sample inputs run through
the code under test without problems.
+If you have a large corpus (either generated by fuzzing or acquired by other means)
+you may want to minimize it while still preserving the full coverage. One way to do that
+is to use the `-merge=1` flag:
+
+.. code-block:: console
+
+ mkdir NEW_CORPUS_DIR # Store minimized corpus here.
+ ./my-fuzzer -merge=1 NEW_CORPUS_DIR FULL_CORPUS_DIR
Getting Started
===============
``-merge``
If set to 1, any corpus inputs from the 2nd, 3rd etc. corpus directories
that trigger new code coverage will be merged into the first corpus
- directory. Defaults to 0.
+ directory. Defaults to 0. This flag can be used to minimize a corpus.
``-reload``
If set to 1 (the default), the corpus directory is re-read periodically to
check for new inputs; this allows detection of new inputs that were discovered
"time in seconds to run the fuzzer.")
FUZZER_FLAG_INT(help, 0, "Print help.")
FUZZER_FLAG_INT(merge, 0, "If 1, the 2-nd, 3-rd, etc corpora will be "
- "merged into the 1-st corpus. Only interesting units will be taken.")
+ "merged into the 1-st corpus. Only interesting units will be taken. "
+ "This flag can be used to minimize a corpus.")
FUZZER_FLAG_INT(use_counters, 1, "Use coverage counters")
FUZZER_FLAG_INT(use_indir_calls, 1, "Use indirect caller-callee counters")
FUZZER_FLAG_INT(use_traces, 0, "Experimental: use instruction traces")