So far we neither compile-tested nor run any of the new fuzzers in our CI,
which led to some build failures of the fuzzer code in the past weeks.
To avoid this problem, add a job to compile the fuzzer code and run some
loops (which likely don't find any new bugs via fuzzing, but at least we
know that the code can still be run).
A nice side-effect of this test is that the leak tests are enabled here,
so we should now notice some of the memory leaks in our code base earlier.
Message-Id: <
20200716100950.27396-1-thuth@redhat.com>
Reviewed-by: Alexander Bulekov <alxndr@bu.edu>
Signed-off-by: Thomas Huth <thuth@redhat.com>
IMAGE: fedora
CONFIGURE_ARGS: --cc=clang --cxx=clang++
TARGETS: alpha-softmmu arm-softmmu m68k-softmmu mips64-softmmu
- ppc-softmmu s390x-softmmu x86_64-softmmu arm-linux-user
+ ppc-softmmu s390x-softmmu arm-linux-user
MAKE_CHECK_ARGS: check
+build-fuzzer:
+ <<: *native_build_job_definition
+ variables:
+ IMAGE: fedora
+ script:
+ - mkdir build
+ - cd build
+ - ../configure --cc=clang --cxx=clang++ --enable-fuzzing
+ --enable-sanitizers --target-list=x86_64-softmmu
+ - make -j"$JOBS" all check-build x86_64-softmmu/fuzz
+ - make check
+ - for fuzzer in i440fx-qos-fork-fuzz i440fx-qos-noreset-fuzz
+ i440fx-qtest-reboot-fuzz virtio-scsi-flags-fuzz virtio-scsi-fuzz ; do
+ echo Testing ${fuzzer} ... ;
+ x86_64-softmmu/qemu-fuzz-x86_64 --fuzz-target=${fuzzer} -runs=1000
+ || exit 1 ;
+ done
+
build-tci:
<<: *native_build_job_definition
variables: