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

[Thomas Huth]

On 17/07/2020 15.20, Alexander Bulekov wrote:
> On 200717 0951, Thomas Huth wrote:
>> On 17/07/2020 07.40, Thomas Huth wrote:
[...]
>> 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"

Thanks, that did the trick:

 https://gitlab.com/huth/qemu/-/jobs/644354706#L3616

... that also explains why I haven't seen it in my other tests where I
am using the --fuzz-target parameter : The leak only happens if the
fuzz-target is encoded in the program name - looks like we have to free
the memory returned by g_path_get_dirname() there...

 Thomas