1 files changed, 114 insertions, 3 deletions
diff --git a/docs/FAQ.md b/docs/FAQ.md
index 1822e46b..242a379b 100644
--- a/docs/FAQ.md
+++ b/docs/FAQ.md
@@ -29,8 +29,8 @@ If you find an interesting or important question missing, submit it via
   which then implemented their own research and features, making it now by far
   the most flexible and feature rich guided fuzzer available as open source. And
   in independent fuzzing benchmarks it is one of the best fuzzers available,
-  e.g., [Fuzzbench
-  Report](https://www.fuzzbench.com/reports/2020-08-03/index.html).
+  e.g.,
+  [Fuzzbench Report](https://www.fuzzbench.com/reports/2020-08-03/index.html).
 </p></details>
 
 <details>
@@ -103,6 +103,42 @@ If you find an interesting or important question missing, submit it via
   to itself, this too would be an edge.
 </p></details>
 
+<details>
+  <summary id="should-you-ever-stop-afl-fuzz-minimize-the-corpus-and-restart">Should you ever stop afl-fuzz, minimize the corpus and restart?</summary><p>
+
+  To stop afl-fuzz, minimize it's corpus and restart you would usually do:
+
+  ```
+  Control-C  # to terminate afl-fuzz
+  $ afl-cmin -T nproc -i out/default/queue -o minimized_queue -- ./target
+  $ AFL_FAST_CAL=1 AFL_CMPLOG_ONLY_NEW=1 afl-fuzz -i minimized_queue -o out2 [other options] -- ./target
+  ```
+
+  If this improves fuzzing or not is debated and no consensus has been reached
+  or in-depth analysis been performed.
+
+  On the pro side:
+    * The queue/corpus is reduced (up to 20%) by removing intermediate paths
+      that are maybe not needed anymore.
+
+  On the con side:
+    * Fuzzing time is lost for the time the fuzzing is stopped, minimized and
+      restarted.
+
+  The the big question:
+    * Does a minimized queue/corpus improve finding new coverage or does it
+      hinder it?
+
+  The AFL++ team's own limited analysis seem to to show that keeping
+  intermediate paths help to find more coverage, at least for afl-fuzz.
+
+  For honggfuzz in comparison it is a good idea to restart it from time to
+  time if you have other fuzzers (e.g: AFL++) running in parallel to sync
+  the finds of other fuzzers to honggfuzz as it has no syncing feature like
+  AFL++ or libfuzzer.
+
+</p></details>
+
 ## Targets
 
 <details>
@@ -171,6 +207,14 @@ If you find an interesting or important question missing, submit it via
   The more "unstable" edges there are, the harder it is for AFL++ to identify
   valid new paths.
 
+  If you fuzz in persistent mode (`AFL_LOOP` or `LLVMFuzzerTestOneInput()`
+  harnesses, a large number of unstable edges can mean that the target keeps
+  internal state and therefore it is possible that crashes cannot be replayed.
+  In such a case do either **not** fuzz in persistent mode (remove `AFL_LOOP()`
+  from your harness or call `LLVMFuzzerTestOneInput()` harnesses with `@@`),
+  or set a low  `AFL_LOOP` value, e.g. 100, and enable `AFL_PERSISTENT_RECORD`
+  in `config.h` with the same value.
+
   A value above 90% is usually fine and a value above 80% is also still ok, and
   even a value above 20% can still result in successful finds of bugs. However,
   it is recommended that for values below 90% or 80% you should take
@@ -229,7 +273,8 @@ If you find an interesting or important question missing, submit it via
   If this is not a viable option, you can set `AFL_IGNORE_PROBLEMS=1` but then
   the existing map will be used also for the newly loaded libraries, which
   allows it to work, however, the efficiency of the fuzzing will be partially
-  degraded.
+  degraded. Note that there is additionally `AFL_IGNORE_PROBLEMS_COVERAGE` to
+  additionally tell AFL++ to ignore any coverage from the late loaded libaries.
 </p></details>
 
 <details>
@@ -255,3 +300,69 @@ If you find an interesting or important question missing, submit it via
 
   Solution: `git pull ; make clean install` of AFL++.
 </p></details>
+
+<details>
+  <summary id="afl-map-size-warning">AFL++ map size warning.</summary><p>
+
+  When you run a large instrumented program stand-alone or via afl-showmap
+  you might see a warning like the following:
+
+  ```
+  Warning: AFL++ tools might need to set AFL_MAP_SIZE to 223723 to be able to run this instrumented program if this crashes!
+  ```
+
+  Depending how the target works it might also crash afterwards.
+
+  Solution: just do an `export AFL_MAP_SIZE=(the value in the warning)`.
+</p></details>
+
+<details>
+  <summary id="linker-errors">Linker errors.</summary><p>
+
+  If you compile C++ harnesses and see `undefined reference` errors for
+  variables named `__afl_...`, e.g.:
+
+  ```
+  /usr/bin/ld: /tmp/test-d3085f.o: in function `foo::test()':
+  test.cpp:(.text._ZN3fooL4testEv[_ZN3fooL4testEv]+0x35): undefined reference to `foo::__afl_connected'
+  clang: error: linker command failed with exit code 1 (use -v to see invocation)
+  ```
+
+  Then you use AFL++ macros like `__AFL_LOOP` within a namespace and this
+  will not work.
+
+  Solution: Move that harness portion to the global namespace, e.g. before:
+  ```
+  #include <cstdio>
+  namespace foo {
+    static void test() {
+      while(__AFL_LOOP(1000)) {
+        foo::function();
+      }
+    }
+  }
+
+  int main(int argc, char** argv) {
+    foo::test();
+    return 0;
+  }
+  ```
+  after:
+  ```
+  #include <cstdio>
+  static void mytest() {
+    while(__AFL_LOOP(1000)) {
+      foo::function();
+    }
+  }
+  namespace foo {
+    static void test() {
+      mytest();
+    }
+  }
+  int main(int argc, char** argv) {
+    foo::test();
+    return 0;
+  }
+  ```
+</p></details>