setcommand instead of
exportto set the environment variable (step 4). Note that these commands are intended to be used with cmd.exe, not PowerShell. Also, you may find these tips on how to debug an ASAN instrumented binary helpful.
The majority of the bugs reported by ClusterFuzz have Reproducible label. That means there is a testcase that can be used to reliably reproduce the crash.
Download the testcase from ClusterFuzz. If you are CCed on an issue filed by ClusterFuzz, a link to it is next to “Reproducer testcase” in the bug description.
For the rest of this walkthrough, we call the path of this file:
$TESTCASE_PATH and the fuzz target you want to reproduce a crash on:
$FUZZER_NAME (provided as “Fuzz target binary” in the bug description).
Generate gn build configuration:
gn args out/fuzz
This will open up an editor. Copy the gn configuration parameters from the values provided in
GN Config section in the ClusterFuzz testcase report.
autoninja -C out/fuzz $FUZZER_NAME
*SAN_OPTIONSenvironment variable as provided in the
Crash Stacktracesection in the testcase report. Here is an example value of
ASAN_OPTIONSthat is similar to its value on ClusterFuzz:
out/fuzz/$FUZZER_NAME -runs=100 $TESTCASE_PATH
If you see an un-symbolized stacktrace, please see the instructions here.
File a bug if you run into any issues.
ClusterFuzz generally does not report issues that it cannot reliably reproduce, unless the following condition is met. If a certain crash is occurring often enough, such a crash might be reported with Unreproducible label and an explicit clarification that there is no convenient way to reproduce it. There are two ways to work with such crashes.
Try a speculative fix based on the stacktrace. Once the fix is landed, wait a couple days and then check Crash Statistics section on the ClusterFuzz testcase report page. If the fix works out, you will see that the crash is not happening anymore. If the crash does not occur again for a little while, ClusterFuzz will automatically close the issue as Verified.
(libFuzzer only) Try to reproduce the whole fuzzing session. This workflow is very similar to the one described above for the Reproducible crashes. The only differences are:
gsutil cp gs://clusterfuzz-libfuzzer-backup/corpus/libfuzzer/$FUZZER_NAME/latest.zip .
out/fuzz/$FUZZER_NAME -timeout=25 -rss_limit_mb=2048 -print_final_stats=1 $CORPUS_DIRECTORY_FROM_THE_PREVIOUS_STEP
Waiting for a crash to occur may take some time (up to 1hr), but if it happens, you will be able to test the fix locally and/or somehow debug the issue.
ClusterFuzz does crash input minimization automatically, and a typical crash report has two testcases available for downloading:
If you would like to further minimize a testcase, run the fuzz target with the two additional arguments:
The full command would be:
out/fuzz/$FUZZER_NAME -minimize_crash=1 -exact_artifact_path=<minimized_testcase_path> $TESTCASE_PATH
This might be useful for large testcases that make it hard to identify a root cause of a crash. You can leave the minimization running locally for a while (e.g. overnight) for better results.