Open mhlakhani opened 3 years ago
I ran into the same issue trying to integrate libbpf
in https://github.com/google/oss-fuzz/pull/6608. I'm not sure what the projects had in common though :-)
@jonathanmetzman looks like it wasn't caught in https://github.com/google/oss-fuzz/pull/6608/checks?check_run_id=3917061555 because the CI didn't run something like
infra/helper.py coverage --no-corpus-download libbpf
in addition to infra/helper.py build_fuzzers --clean --sanitizer=coverage libbpf
.
I "fixed" it in https://github.com/google/oss-fuzz/pull/6608 by linking zlib
statically instead of copying it to "$OUT/lib" and patching rpath
:
-$CXX $CXXFLAGS $LIB_FUZZING_ENGINE bpf-object-fuzzer.o src/libbpf.a $(pwd)/elfutils/libelf/libelf.a -lz -o "$OUT/bpf-object-fuzzer"
-
-mkdir -p "$OUT/LIB"
-cp $(ldd "$OUT/bpf-object-fuzzer" | grep libz | awk '{ print $3 }') "$OUT/LIB"
-patchelf --set-rpath '$ORIGIN/LIB' "$OUT/bpf-object-fuzzer"
-ldd "$OUT/bpf-object-fuzzer"
+ZLIB_DIR=$(pkg-config --variable=libdir zlib)
+$CXX $CXXFLAGS $LIB_FUZZING_ENGINE bpf-object-fuzzer.o src/libbpf.a "$(pwd)/elfutils/libelf/libelf.a" "$ZLIB_DIR/libz.a" -o "$OUT/bpf-object-fuzzer"
Though I have to admit I have no idea why fuzz targets linked dynamically against libraries put in $OUT/lib
trigger this issue.
@mhlakhani, does @evverx response work for you.
Hi! @lnicco and I were looking into https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38519#c2 which is a coverage build failure for proxygen.
Looking at the logs, it seems to be we're hitting UB in llvm itself:
Would anyone here have guidance on how we can look into this or reproduce the issue?
I did see a bunch of open issues around coverage build failures, but https://github.com/google/oss-fuzz/issues/6268 seemed Rust specific while proxygen is mostly C++. Please let me know if we should just wait for the fix for that to roll out