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, 5 insertions, 2 deletions

diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md
index 760d780e..65a6de3d 100644
--- a/docs/fuzzing_in_depth.md
+++ b/docs/fuzzing_in_depth.md
@@ -201,7 +201,10 @@ The following sanitizers have built-in support in AFL++:
   security issue, but for developers this can be very valuable. Note that unlike
   the other sanitizers above this needs `__AFL_LEAK_CHECK();` added to all areas
   of the target source code where you find a leak check necessary! Enabled with
-  `export AFL_USE_LSAN=1` before compiling.
+  `export AFL_USE_LSAN=1` before compiling. To ignore the memory-leaking check
+  for certain allocations, `__AFL_LSAN_OFF();` can be used before memory is 
+  allocated, and `__AFL_LSAN_OFF;` afterwards. Memory allocated between these
+  two macros will not be checked for memory leaks.
 
 It is possible to further modify the behavior of the sanitizers at run-time by
 setting `ASAN_OPTIONS=...`, `LSAN_OPTIONS` etc. - the available parameters can
@@ -890,4 +893,4 @@ covered.
 
 Note that there are also a lot of tools out there that help fuzzing with AFL++
 (some might be deprecated or unsupported), see
-[third_party_tools.md](third_party_tools.md).
\ No newline at end of file
+[third_party_tools.md](third_party_tools.md).