Describe the bug
My target libevent (release-2.1.8-stable: https://github.com/libevent/libevent/releases/tag/release-2.1.8-stable). I use multi-threaded fuzzing. Fuzzer with Intel-laf finds crashes (in func bracket_addr_ok(const char *s, const char *eos) at http.c:4550). But if I run it on asan build, it doesn't crash. Is this behavior caused by deoptimization of laf and should the found crash be interpreted as a false positive or am I missing something?

To Reproduce
Steps to reproduce the behavior:
./http-fuzz-laf ./id:000059,sig:11,src:000051,time:727642705,execs:2335007031,op:havoc,rep:2
./http-fuzz-asan ./id:000059,sig:11,src:000051,time:727642705,execs:2335007031,op:havoc,rep:2

Expected behavior
LAF one - crash with Segmentation fault (core dumped)
ASAN one - no crash

Screen output/Screenshots

Additional context
On screenshot: debug ran laf bin with crash seed, n_chars=164 and it’s > 64, but when I tap step over, it bypasses return 0 and executes memcpy to buf of 64 values 164 values witch bring to buffer overflow.
If I run same crash file with asan bin or just bin with basic afl instrumentation - crash not happens.

Building and fuzzing:

1. Build libevent:
   CC=afl-clang-lto CXX=afl-clang-lto++ CFLAGS="-Wno-error -g -O0" CXXFLAGS="-Wno-error -g -O0" ./configure --disable-shared --disable-openssl --disable-thread-support
   AFL_USE_ASAN=1 make OR AFL_LLVM_LAF_ALL=1 make
2. Build fuzzer:
   AFL_USE_ASAN=1 afl-clang-lto http-fuzz.c -L/usr/local/lib -l:libevent.a -g -O0 -o http-fuzz-asan
   OR
   AFL_LLVM_LAF_ALL=1 afl-clang-lto http-fuzz.c -L/usr/local/lib -l:libevent.a -g -O0 -o http-fuzz-laf
3. Run fuzz:
   afl-fuzz -i $in_dir -o $out_dir -t 10 -m none -- http-fuzz-laf @@

Files
files.zip