BAD BUILD: ASan build of <libreoffice-fuzzer> seems to be compiled with MSan.

[caolanm]

Since the 25th Nov the libreoffice build fails with the above message on the libreoffice fuzzers
https://oss-fuzz-build-logs.storage.googleapis.com/index.html#libreoffice
e..g. Step #32: BAD BUILD: ASan build of /tmp/not-out/xpmfuzzer seems to be compiled with MSan.
that message appears to come from infra/base-images/base-runner/bad_build_check
which has...

CALL_INSN="callq\s+[0-9a-f]+\s+<"
MSAN_CALLS=$(objdump -dC $FUZZER | egrep "${CALL_INSN}__msan" -c)
check_asan_build $FUZZER ... $MSAN_CALLS ...
which errors out of MSAN_CALLS is > -

locally I do get...

objdump -dC rasfuzzer|egrep __msan
... mov 0x76f6354(%rip),%rcx ... <__msan_scoped_disable_interceptor_checks>
... mov 0x76f6337(%rip),%rcx ... <__msan_scoped_enable_interceptor_checks>
... mov 0x76f631a(%rip),%rax ... <__msan_unpoison>
... mov 0x76f6304(%rip),%rax ... <__msan_unpoison_param>

but no actual call of a __msan* function, though I will try again after a: python infra/helper.py pull_images

[inferno-chromium]

Looks like something happened with envoy as well
https://oss-fuzz-build-logs.storage.googleapis.com/index.html#envoy

Step #32: Broken fuzz targets (39):
Step #32: buffer_fuzz_test:
Step #32: BAD BUILD: ASan build of /tmp/not-out/buffer_fuzz_test seems to be compiled with MSan.
Step #32: codec_fuzz_test:
Step #32: BAD BUILD: ASan build of /tmp/not-out/codec_fuzz_test seems to be compiled with MSan.
Step #32: codec_impl_fuzz_test:
Step #32: BAD BUILD: ASan build of /tmp/not-out/codec_impl_fuzz_test seems to be compiled with MSan.
Step #32: compressor_fuzz_test:
Step #32: BAD BUILD: ASan build of /tmp/not-out/compressor_fuzz_test seems to be compiled with MSan.
Step #32: config_fuzz_test:
Step #32: BAD BUILD: ASan build of /tmp/not-out/config_fuzz_test seems to be compiled with MSan.
Step #32: conn_manager_impl_fuzz_test:
Step #32: BAD BUILD: ASan build of /tmp/not-out/conn_manager_impl_fuzz_test seems to be compiled with MSan.

[inferno-chromium]

Some regression landed on 24th as builds broken starting 25th. could be some clang regression, don't see anything interesting on our side.

[oliverchang]

Looks honggfuzz specific. Possibly google/honggfuzz@e067013 ? @robertswiecki

[oliverchang]

We probably need to make this regex a bit more specific, (not just checking for __msan) or check that there are multiple calls above some threshold.

[robertswiecki]

FWIW those calls are weak, maybe this can be used

$ nm libhfuzz/libhfuzz.a  | grep __msan
                 w __msan_poison
                 w __msan_unpoison

On the final binary it's the same

$ nm a | grep __msan
                 w __msan_poison
                 w __msan_unpoison

[mihaimaruseac]

TF has the same issue

[inferno-chromium]

@mihaimaruseac - tensorflow is now green, see https://oss-fuzz-build-logs.storage.googleapis.com/index.html#tensorflow
Others should get green by tmrw as well since @oliverchang fix is in.

[oliverchang]

libreoffice is now green, while envoy looks broken due to an unrelated AFL issue.

[asraa]

Yesterday I fixed unrelated build failures (a bad parse_dictionary error, and an early fail for a fuzz test) on libfuzzer, but see the too many ASan calls on on libfuzzer/UBSan builds error: https://oss-fuzz-build-logs.storage.googleapis.com/log-3fe6bcd5-c846-481a-baac-311f239d9f36.txt

Step #14: BAD BUILD: UBSan build of /tmp/not-out/h1_capture_direct_response_fuzz_test seems to be compiled with ASan.

On a local build it passes:

$ python infra/helper.py build_image envoy && python infra/helper.py build_fuzzers --sanitizer undefined --engine libfuzzer --architecture x86_64 envoy && python infra/helper.py check_build --sanitizer undefined --engine libfuzzer --architecture x86_64 envoy
[...]
INFO: performing bad build checks for /tmp/not-out/h2_capture_direct_response_persistent_fuzz_test
INFO: performing bad build checks for /tmp/not-out/utility_fuzz_test
Check build passed.