proxygen coverage build failures

[mhlakhani]

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:

Step #5: UndefinedBehaviorSanitizer:DEADLYSIGNAL
Step #5: ==31==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address (pc 0x000000864360 bp 0x000000ad33f0 sp 0x7ffd5e3217d0 T31)
Step #5: ==31==The signal is caused by a READ memory access.
Step #5: ==31==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
Step #5:     #0 0x864360 in __llvm_write_binary_ids (out/libfuzzer-coverage-x86_64/ProxygenHTTP1xFuzzer+0x864360)
Step #5:     #1 0x863a09 in lprofWriteDataImpl (out/libfuzzer-coverage-x86_64/ProxygenHTTP1xFuzzer+0x863a09)
Step #5:     #2 0x86395b in lprofWriteData (out/libfuzzer-coverage-x86_64/ProxygenHTTP1xFuzzer+0x86395b)
Step #5:     #3 0x86234d in writeFile InstrProfilingFile.c
Step #5:     #4 0x8620b1 in __llvm_profile_write_file (out/libfuzzer-coverage-x86_64/ProxygenHTTP1xFuzzer+0x8620b1)
Step #5:     #5 0x7fca09491a26  (/lib/x86_64-linux-gnu/libc.so.6+0x49a26)
Step #5:     #6 0x7fca09491bdf in exit (/lib/x86_64-linux-gnu/libc.so.6+0x49bdf)
Step #5:     #7 0x43728b in fuzzer::Merge(fuzzer::Fuzzer*, fuzzer::FuzzingOptions&, std::__Fuzzer::vector<std::__Fuzzer::basic_string<char, std::__Fuzzer::char_traits<char>, std::__Fuzzer::allocator<char> >, std::__Fuzzer::allocator<std::__Fuzzer::basic_string<char, std::__Fuzzer::char_traits<char>, std::__Fuzzer::allocator<char> > > > const&, std::__Fuzzer::vector<std::__Fuzzer::basic_string<char, std::__Fuzzer::char_traits<char>, std::__Fuzzer::allocator<char> >, std::__Fuzzer::allocator<std::__Fuzzer::basic_string<char, std::__Fuzzer::char_traits<char>, std::__Fuzzer::allocator<char> > > > const&, char const*) cxa_noexception.cpp
Step #5:     #8 0x43a931 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) cxa_noexception.cpp
Step #5:     #9 0x463a72 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
Step #5:     #10 0x7fca0946f0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
Step #5:     #11 0x41228d in _start (out/libfuzzer-coverage-x86_64/ProxygenHTTP1xFuzzer+0x41228d)
Step #5: 
Step #5: DEDUP_TOKEN: __llvm_write_binary_ids--lprofWriteDataImpl--lprofWriteData
Step #5: UndefinedBehaviorSanitizer can not provide additional info.
Step #5: SUMMARY: UndefinedBehaviorSanitizer: SEGV (out/libfuzzer-coverage-x86_64/ProxygenHTTP1xFuzzer+0x864360) in __llvm_write_binary_ids

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

[evverx]

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.

[evverx]

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.

[inferno-chromium]

@mhlakhani, does @evverx response work for you.