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

[Thomas Huth <thuth@redhat.com>]

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...

 Thomas