Re: [PATCH] gitlab-ci.yml: Add oss-fuzz build tests

[Alexander Bulekov]

On 200717 0951, Thomas Huth wrote:
> On 17/07/2020 07.40, Thomas Huth wrote:
> > On 16/07/2020 18.33, Alexander Bulekov wrote:
> >> This tries to build and run the fuzzers with the same build-script used
> >> by oss-fuzz. This doesn't guarantee that the builds on oss-fuzz will
> >> also succeed, since oss-fuzz provides its own compiler and fuzzer vars,
> >> but it can catch changes that are not compatible with the the
> >> ./scripts/oss-fuzz/build.sh script.
> >> The strange way of finding fuzzer binaries stems from the method used by
> >> oss-fuzz:
> >> https://github.com/google/oss-fuzz/blob/master/infra/base-images/base-runner/targets_list
> >>
> >> Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
> >> ---
> >>
> >> Similar to Thomas' patch:
> >>
> >>> Note: This patch needs two other patches merged first to work correctly:
> >>
> >>> - 'fuzz: Expect the cmdline in a freeable GString' from Alexander
> >>
> >>> - 'qom: Plug memory leak in "info qom-tree"' from Markus
> >>
> >> Otherwise the test will fail due to detected memory leaks.
> >>
> >> Fair warning: I haven't been able to trigger this new job yet. I tried
> >> to run the pipeline with these changes on my forked repo on gitlab, but
> >> did not reach the build-oss-fuzz. I think this is due to some failures
> >> in the Containers-layer-2 stage:
> 
> I think I've got it basically working like this:
> 
> build-oss-fuzz:
>   <<: *native_build_job_definition
>   variables:
>     IMAGE: fedora
>   script:
>     - mkdir build-oss-fuzz
>     - CC="clang" CXX="clang++" CFLAGS="-fsanitize=address"
>       ./scripts/oss-fuzz/build.sh
>     - for fuzzer in $(find build-oss-fuzz/DEST_DIR/ -executable -type f
>                       | grep -v slirp); do
>         grep "LLVMFuzzerTestOneInput" ${fuzzer} > /dev/null 2>&1 ||
> continue ;
>         echo Testing ${fuzzer} ... ;
>         "${fuzzer}" -runs=1000 || exit 1 ;
>       done
> 
> However, it still triggered a memory leak and thus the pipeline failed:
> 
>  https://gitlab.com/huth/qemu/-/jobs/643472695
> 
> ... and this was with all the other "leak fix" patches already applied.
> Is there an easy way to debug that issue? That information from the
> LeakSanitizer looks pretty sparse...

Strange... Especially since Philippe didn't get the same error. We
should probably add -seed=1 after -runs=1000, to make sure the fuzzer is
using the same rng seed. That said, I just ran the fuzzer for 50k
iterations, and still could not reproduce the leak...

This environment variable should fix the partial stacktrace, so we don't
have to guess next time:
ASAN_OPTIONS="fast_unwind_on_malloc=0"
-Alex

>  Thomas
>