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
