These messages are coming from https://cs.chromium.org/chromium/src/chrome/utility/safe_browsing/mac/udif.cc?l=784

Robert and Nathan, do you have any suggestions how we can suppress it?

Looks like NOTIMPLEMENTED() ignores log_level (https://cs.chromium.org/chromium/src/chrome/utility/safe_browsing/mac/fuzzer.cc?l=21).

If there is no easy way to remove those messages during compile time, we can do the following: https://codereview.chromium.org/2665983003

It seems like a bug in logging.h that the log_level is getting ignored.

Hm, maybe it doesn't ignore actually:

with NOTIMPLEMENTED_POLICY of 4 and 5 it goes through LOG(ERROR) or LOG_IF(ERROR, ...): https://cs.chromium.org/chromium/src/base/logging.h?type=cs&q=NOTIMPLEMENTED&l=1070

Both these cases are going through LOG_IS_ON(severity): https://cs.chromium.org/chromium/src/base/logging.h?type=cs&q=%22define+log%22&l=377

And it calls ::logging::ShouldCreateLogMessage(::logging::LOG_##severity) : https://cs.chromium.org/chromium/src/base/logging.h?type=cs&q=ShouldCreateLogMessage+package:%5Echromium$&l=352

which does explicit check against min log level: https://cs.chromium.org/chromium/src/base/logging.cc?q=ShouldCreateLogMessage+package:%5Echromium$&l=410&dr=CSs

Thus, I don't understand why it is being printed....

> Thus, I don't understand why it is being printed....

I read the code the same as you and don't understand how this is getting printed :/

I'm suspicious about InitLogging call:

InitLogging (https://cs.chromium.org/chromium/src/chrome/utility/safe_browsing/mac/fuzzer.cc?l=22) creates VlogInfo (https://cs.chromium.org/chromium/src/base/logging.cc?l=372)

which saves pointer to g_min_log_level (https://cs.chromium.org/chromium/src/base/vlog.cc?l=51) into its private member (https://cs.chromium.org/chromium/src/base/vlog.h?type=cs&l=57)

and then may change it to a negative value at some point: https://cs.chromium.org/chromium/src/base/vlog.cc?type=cs&l=121

But from what I can tell, that is only called from BaseInitLoggingImpl, which should only be called by InitLogging.

Looks like we need to find someone with Mac who can debug these things a bit.

mac triage: I think thakis@ might be the hero we need for Mac base problems.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/aa8ec6485091dda9862eb62960b881a60ef9e132

commit aa8ec6485091dda9862eb62960b881a60ef9e132
Author: mmoroz <mmoroz@chromium.org>
Date: Tue Feb 07 14:07:22 2017

Add close_fd_mask=2 to suppress NOTIMPLEMENTED in safe_browsing_dmg_fuzzer.

BUG= 687076 

TBR=rsesek@chromium.org,nparker@chromium.org

Review-Url: https://codereview.chromium.org/2665983003
Cr-Commit-Position: refs/heads/master@{#448616}

[modify] https://crrev.com/aa8ec6485091dda9862eb62960b881a60ef9e132/chrome/utility/safe_browsing/mac/BUILD.gn

I've updated the summary as the initial issue with the fuzzer has been fixed by other means.

So it looks like this is no longer related to this specific fuzzer.

It looks like the LLVMFuzzerInitialize() function is getting stripped out:

% nm out/libfuzzer/safe_browsing_dmg_fuzzer  | grep LLVM
00000001000012d0 t _LLVMFuzzerTestOneInput

Looking at the ldflags in the ninja file, we are passing -Wl,-dead_strip. And since that function is not reachable by the entrypoint or any exported function, it's likely the linker is just removing it.

Using __attribute__((used)) gets it to show up:
% nm out/libfuzzer/safe_browsing_dmg_fuzzer  | grep LLVM                                
0000000100001e50 t _LLVMFuzzerInitialize
0000000100002050 t _LLVMFuzzerTestOneInput

But it is still not being found by the FuzzerDriver() ExternalFunctions, since EF goes through dlsym and the symbol is not marked as exported. This is in contrast to LLVMFuzzerTestOneInput() which is passed as a function pointer in FuzzerMain.cpp, rather than being resolved through dyld.

Adding __attribute__((visibility("default"))) along with ((used)) prevents the linker from stripping it and puts it in the exported symbol table, so that the FuzzerDriver can find it. Then it actually runs, calls SetMinLogLevel, and the NOTIMPLEMETNEDs are quiet.

Also -RV-G since nothing sensitive here.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d88ebf8b17284d37b9dc083b8282c6e34786676c

commit d88ebf8b17284d37b9dc083b8282c6e34786676c
Author: Robert Sesek <rsesek@chromium.org>
Date: Tue Oct 17 21:54:41 2017

Ensure _LLVMFuzzerInitialize is always exported and marked used on Mac.

The linker's -dead_strip was removing the fuzzer initializer because it
was unreachable and not exported. This adds a new libfuzzer_exports.h
header that fuzzers can include to ensure the symbols have the proper
visibility.

Bug:  687076 
Change-Id: I8fe5c523ade491a48cd7abbf85c69edb872c97db
Reviewed-on: https://chromium-review.googlesource.com/721340
Reviewed-by: Varun Khaneja <vakh@chromium.org>
Reviewed-by: Max Moroz <mmoroz@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#509558}
[modify] https://crrev.com/d88ebf8b17284d37b9dc083b8282c6e34786676c/chrome/utility/safe_browsing/mac/BUILD.gn
[modify] https://crrev.com/d88ebf8b17284d37b9dc083b8282c6e34786676c/chrome/utility/safe_browsing/mac/dmg_fuzzer.cc
[modify] https://crrev.com/d88ebf8b17284d37b9dc083b8282c6e34786676c/chrome/utility/safe_browsing/mac/hfs_fuzzer.cc
[modify] https://crrev.com/d88ebf8b17284d37b9dc083b8282c6e34786676c/testing/libfuzzer/fuzzer_test.gni
[add] https://crrev.com/d88ebf8b17284d37b9dc083b8282c6e34786676c/testing/libfuzzer/libfuzzer_exports.h

kcc, having to mark LLVMFuzzerInitialize explicitly as used seems pretty strange. clang should probably mark it as used if building in fuzzer mode, similar to how main() doesn't get stripped either?

I'm not sure it's strange in the mode we're currently building fuzzers. But on the CL we discussed using -fsanitize=fuzzer, and I do think it's weird that it gets stripped in that mode. But per #13, marking it used is not sufficient; we need to mark it exported too.

The root issue is how linker handles weak function declarations on Mac: https://chromium.googlesource.com/chromium/llvm-project/compiler-rt/lib/fuzzer.git/+/master/FuzzerExtFunctionsWeak.cpp#9

I've tried to discuss a potential solution on llvm-dev mailing list: http://lists.llvm.org/pipermail/llvm-dev/2017-September/117185.html

but ended up with a conclusion that it would be simpler to switch to -fsanitize=fuzzer, given that anyway we need to switch to that.

The switch might be not very straightforward (Robert tried doing that, but it didn't work for him: https://chromium-review.googlesource.com/c/chromium/src/+/721340#message-ec6a33f5ee6da444344eb212cbeba12733919524), but I'm quite sure that it should work. I need to take a closer look at that. For now, the solution suggested by Robert looks good to me.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ae3aae5748ac6e4a2b26e739ce99256c3e29f192

commit ae3aae5748ac6e4a2b26e739ce99256c3e29f192
Author: Max Moroz <mmoroz@chromium.org>
Date: Wed Oct 18 01:50:19 2017

[libFuzzer] Use full path to libfuzzer_exports.h in fuzzer_test.gni.

TBR=rsesek@chromium.org

Bug:  687076 
Change-Id: Ia3e3f412fe8fa61c19887573e01cffd0ed751bff
Reviewed-on: https://chromium-review.googlesource.com/724729
Reviewed-by: Max Moroz <mmoroz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#509650}
[modify] https://crrev.com/ae3aae5748ac6e4a2b26e739ce99256c3e29f192/testing/libfuzzer/fuzzer_test.gni