In D93412#2461136, @Dor1s wrote:

@morehouse @metzman Matt and Jonathan, could any of you please commit this? I don't have a checkout handy plus haven't figured out my current CLA situation.

Disabling on Linux was right call as http://lab.llvm.org:8011/#/builders/112/builds/1191/steps/5/logs/stdio is failing with ASAN_OPTIONS fix.

Looks like my fix broke windows.
http://lab.llvm.org:8011/#/builders/127/builds/1548
I'm going to undo my Win fix and disable it on Linux for now (https://github.com/llvm/llvm-project/commit/91703085f53428ea6305770d41db148e0ebbdea7)
I'll try again if http://lab.llvm.org:8011/#/builders/112/builds/1191 passes since I think it contains https://github.com/llvm/llvm-project/commit/a3be1287091463f4099cdb1710883645329cda7e
The problem is, I don't really know how I can set an env var in a way that works on Linux but doesn't cause failure on Win.
I have both platforms to test though

In D89755#2397497, @morehouse wrote:

Does setting ASAN_OPTIONS=allocator_may_return_null=1 help at all? I think it would cause std::bad_alloc on these platforms, which should also crash.

Sorry, didn't notice your response.
Do you need me to merge this for you?

In D89755#2358475, @jopletch wrote:

Address review comments, apologies for the delay and incorrectly formatted patch. Should have a test added shortly, but I'm running into some problems executing the test suite on Windows. Are failures expected on Windows, or is it more likely there are problems with my environment? Specifically the testing suite seems to be expecting bash-like environment. Is it expected to run ninja from wsl or cygwin?

In D89755#2358475, @jopletch wrote:

Address review comments, apologies for the delay and incorrectly formatted patch. Should have a test added shortly, but I'm running into some problems executing the test suite on Windows. Are failures expected on Windows, or is it more likely there are problems with my environment? Specifically the testing suite seems to be expecting bash-like environment. Is it expected to run ninja from wsl or cygwin?

This change was a bit hard to review since it doesn't include full context (See https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface).

This change LGTM.
I'll let @vitalybuka decide if he wants to accept.

Thanks!

LGTM

Sorry I didn't review this. LGTM

still LGTM

Mostly LGTM.
What's hash for? To seed an RNG?
I'm not 100% hashing the whole array is the right way to do things but it might be better than nothing.
I guess changing this is possible but not ideal since corpus elements won't map to the same behavior if we change it to say, the last byte or something similar.

LGTM

LGTM. This seems like a generic way of handling this and is especially useful when using LD_PRELOAD to load custom mutators since iirc LD_PRELOAD doesn't make so much noise when it fails.

• fix comment

• fmt

• hoist as requested

Demo https://jonathanmetzman.github.io/wasm-fuzzing-demo/brotli/decode_fuzzer.html

• fix comment

LGTM.
Thanks!

I don't consider myself a Windows expert but I don't see anything problematic from a Windows point of view.

We recreate merged_corpus directory and run the second merge step:

Thanks for looking into making this change. It should be very useful for CF.
I'll try to take a look again tomorrow morning with fresh eyes.

LGTM

Please take a look.
This reenables libFuzzer on i386 on Linux (accidentally disabled here), and fixes a previously failing test.

I'm also thinking i386 libFuzzer is broken on iOS (though I have no way of confirming this) and thus caused the greendragon bot failure: http://green.lab.llvm.org/green/job/clang-stage2-coverage-R/3958/consoleFull#console-section-35

Please take a look.
I could be less conservative here and only disable i386 on Windows but I frankly don't think the risk of breaking other platforms is worth the benefit (nothing).
This is intended to fix https://bugs.chromium.org/p/chromium/issues/detail?id=957971#c5 I've verified that the "fuzzer" target is no longer possible to build on x86 (as opposed to possible but failing as it was before).
It's also worth noting that this breakage is in part caused by libFuzzer building with MSVC (__builtin_clzll isn't supported by MSVC but _BitScanReverse64 is supported, but not on i386) instead of indirectly with clang.

• fix comment

PTAL.

• add missing period

• use exit(1)

• improve message

• improve error message and look for it in tests

• add newline

@kcc I've changed things so that libFuzzer will fail if the argument to -seed_inputs is a non existent file or is empty? What do you think of this change?

• Add more tests to verify we catch empty lists

• Make LF fail if no seed list

• fix bug

• only use @ in argument

• test