# Reproducing OSS-Fuzz issues You've been CC'ed on an OSS-Fuzz issue ([examples](https://bugs.chromium.org/p/oss-fuzz/issues/list)), now what? Before attempting a fix the bug you should be able to reliably reproduce it. Every issue has a reproducer file attached. Download it. If the issue is not public, you will need to login using your Google account that is CC-ed to the bug report. This file contains the bytes that were fed to the [Fuzz Target](http://libfuzzer.info/#fuzz-target). If you have [properly integrated](ideal_integration.md) the fuzz target with your build and test system all you is to run ``` ./fuzz_target_binary REPRODUCER_FILE ``` Depending on the nature of the bug, the fuzz target binary needs to be built with the appropriate sanitizer (e.g. if this is a buffer overflow, with [AddressSanitizer](http://clang.llvm.org/docs/AddressSanitizer.html)). If you are not sure how to build fuzzers within the target, you may also use Docker (([how?](installing_docker.md), [why?](faq.md#why-do-you-use-docker))) commands to replicate the exact build steps used by OSS-Fuzz and then feed the reproducer input to the target. - *Reproduce from nightly sources:*
docker run --rm -v $testcase_file:/testcase -t ossfuzz/$target reproduce $fuzzerIt builds the fuzzer from nightly sources (in the image) and runs it with testcase input. E.g. for libxml2 it will be:
docker run --rm -ti -v ~/Downloads/testcase:/testcase ossfuzz/libxml2 reproduce libxml2_xml_read_memory_fuzzer- *Reproduce from local sources:*
docker run --rm -v $target_checkout_dir:/src/$target \ -v $reproducer_file:/testcase -t ossfuzz/$target reproduce $fuzzerThis is essentially the previous command that additionally mounts local sources into the running container. - *Fix the issue.* Use the previous command to verify you fixed the issue locally. [Use gdb](debugging.md#debugging-fuzzers-with-gdb) if needed. - *Submit the fix.* ClusterFuzz will automatically pick up the changes, recheck the testcase and will close the issue.