Fix LeakSanitizer Usage.

Previously, __lsan_do_leak_check() was run when using __AFL_LEAK_CHECK,
however this was the incorrect function to use. According to the
documentation: "Subsequent calls to this function will have no effect
and end-of-process leak check will not run".
This meant that if the memory did not leak on the first usage of
__AFL_LEAK_CHECK, subsquent calls to this macro would never do anything.

Likewise, it is not possible to use an LSAN suppression list with
symbolize=0, so instead __lsan_disable and __lsan_enable are used to
'ignore' certain memory allocations where needed.

1 files changed, 2 insertions, 1 deletions

diff --git a/docs/env_variables.md b/docs/env_variables.md
index dc79bf9e..7ab5351c 100644
--- a/docs/env_variables.md
+++ b/docs/env_variables.md
@@ -105,7 +105,8 @@ fairly broad use of environment variables instead:
       within your program at a certain point (such as at the end of an
       `__AFL_LOOP()`), you can run the macro  `__AFL_LEAK_CHECK();` which will
       cause an abort if any memory is leaked (you can combine this with the
-      `LSAN_OPTIONS=...` suppression option to suppress some known leaks).
+      `__AFL_LSAN_OFF();` and `__AFL_LSAN_ON();` macros to avoid checking for
+      memory leaks from memory allocated between these two calls.
     - `AFL_USE_MSAN=1` - activates the memory sanitizer (uninitialized memory)
     - `AFL_USE_TSAN=1` - activates the thread sanitizer to find thread race
       conditions