google
Update libfuzzer to LLVM 18
The libfuzzer commit used was an older version which did not seem to be up-to-date with documentation and harness behaviour. This led to assertion failures in the main fuzzer loop in new benchmarks due to not recognising the documented -1 return value.
This updates the libfuzzer version to the latest LLVM release.
Hm, it also seems that no default timeout is set. By default, libfuzzer uses a 20 minute timeout, so this should likely be set to something more reasonable (10 seconds?).
this is what the log from CI says.
2024-08-19T05:08:11.5387571Z #22 0.298 CFLAGS = -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -pthread -Wl,--no-as-needed -Wl,-ldl -Wl,-lm -Wno-unused-command-line-argument -O3
2024-08-19T05:08:11.5389357Z #22 0.298 CXXFLAGS = -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -pthread -Wl,--no-as-needed -Wl,-ldl -Wl,-lm -Wno-unused-command-line-argument -stdlib=libc++ -O3
2024-08-19T05:08:11.5390564Z #22 0.304 Building benchmark bloaty_fuzz_target with fuzzer libfuzzer
2024-08-19T05:08:11.5391129Z #22 0.306 + cd /work
2024-08-19T05:08:11.5391602Z #22 0.306 + cmake -G Ninja -DBUILD_TESTING=false /src/bloaty
2024-08-19T05:08:11.5679392Z #22 0.486 -- The C compiler identification is Clang 15.0.0
2024-08-19T05:08:11.7214436Z #22 0.639 -- The CXX compiler identification is Clang 15.0.0
so it's 15.0.0. that is used. maybe you should apt purge clang-* llvm-* to delete everything first so that /usr/bin/clang wont point to the wrong one
Ah, good catch. Probably why ASAN is mad. I'll copy/paste some more code from the libafl dockerfile.
maybe you should use update-alternative though instead of my snippet. because this is not libafl
so it's 15.0.0. that is used.
I actually worked out that this is not relevant for us; we just have to build the fuzzer with a c++17 compatible version and disable container overflow. There's some weird interaction between fork mode and the old bug benchmark that's too difficult to reasonably debug :sweat_smile: