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