Rooba
/
oss-fuzz
mirror of https://github.com/google/oss-fuzz.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update reproducing.md

This commit is contained in:
inferno-chromium 2016-11-29 11:14:04 -08:00 committed by GitHub
parent 5e8481c3aa
commit 81bcb78498
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
docs/reproducing.md
View File

@ -25,13 +25,13 @@ to replicate the exact build steps used by OSS-Fuzz and then feed the reproducer
- *Reproduce using latest OSS-Fuzz build:*
<pre>
docker run --rm -ti -v <b><i>$testcase_file</i></b>:/testcase ossfuzz/<b><i>$target</i></b> reproduce <b><i>$fuzzer</i></b>
docker run --rm -ti -v <b><i>$testcase_file</i></b>:/testcase ossfuzz/<b><i>$project</i></b> reproduce <b><i>$fuzzer</i></b>
</pre>
It builds the fuzzer from the most recent successful OSS-Fuzz build (usually last night's sources)
and feeds the testcase file to the target function.
E.g. for [libxml2](../target/libxml2) target with fuzzer named `libxml2_xml_read_memory_fuzzer`, it will be:
E.g. for [libxml2](../target/libxml2) project with fuzzer named `libxml2_xml_read_memory_fuzzer`, it will be:
<pre>
docker run --rm -ti -v <b><i>~/Downloads/testcase</i></b>:/testcase ossfuzz/<b><i>libxml2</i></b> reproduce <b><i>libxml2_xml_read_memory_fuzzer</i></b>
@ -39,12 +39,12 @@ docker run --rm -ti -v <b><i>~/Downloads/testcase</i></b>:/testcase ossfuzz/<b><
- *Reproduce using local source checkout:*
<pre>
docker run --rm -ti -v <b><i>$local_source_checkout_dir</i></b>:/src/<b><i>$target</i></b> \
-v <b><i>$testcase_file</i></b>:/testcase ossfuzz/<b><i>$target</i></b> reproduce <b><i>$fuzzer</i></b>
docker run --rm -ti -v <b><i>$local_source_checkout_dir</i></b>:/src/<b><i>$project</i></b> \
-v <b><i>$testcase_file</i></b>:/testcase ossfuzz/<b><i>$project</i></b> reproduce <b><i>$fuzzer</i></b>
</pre>
This is essentially the previous command that additionally mounts local sources into the running container.
- *Fix issue*. Write a patch to fix the issue in your local checkout and then use the previous command to verify the fix (i.e. no crash occurred).
[Use gdb](debugging.md#debugging-fuzzers-with-gdb) if needed.
- *Submit fix*. Submit the fix in the target's repository. ClusterFuzz will automatically pick up the changes, recheck the testcase and will close the issue (in &lt;1 day).
- *Submit fix*. Submit the fix in the project's repository. ClusterFuzz will automatically pick up the changes, recheck the testcase and will close the issue (in &lt; 1 day).
- *Improve fuzzing support*. Consider [improving fuzzing support](ideal_integration.md) in your project's build and test system.