It doesn't make sense to non-deterministically choose between
`CopyPart(..)` and `InsertPart(..)` when it is known that
`InsertPart(..)` will fail.
This upstream's a change from JFS solver's fork of LibFuzzer.
Differential Revision: https://reviews.llvm.org/D45693
llvm-svn: 330687
This test is failing on my Linux box. Just increasing the number of
iterations works around this. The divergence is likely due to
our reliance on `std::shuffle()` which is not guaranteed to have
the same behaviour across platforms.
This is a strong argument for us to implement our own shuffle
function to avoid divergence in behaviour across platforms.
Differential Revision: https://reviews.llvm.org/D45767
llvm-svn: 330390
Summary: With 3 Dictionary objects, each containing space of ~16k DictionaryEntry objects, the MutationDispatcher object is fairly memory heavy. On platforms with a lower default stack size, this can cause panics in FuzzerUnittest as those tests stack-allocate the MutationDispatcher. This may be especially problematic for platforms that do not (yet) have a way to programmatically change their stack size, aside from link-time flags. In general, it seems more prudent to use the heap for an object of this size.
Reviewers: kcc, morehouse
Reviewed By: kcc
Differential Revision: https://reviews.llvm.org/D40926
llvm-svn: 319988
Summary:
To be more portable (especially w.r.t. platforms without system()),
commands should be managed programmatically rather than via string
manipulation on the command line. This change introduces
Fuzzer::Command, with methods to manage arguments and flags, set output
options, and execute the command.
Patch By: aarongreen
Reviewers: kcc, morehouse
Reviewed By: kcc, morehouse
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D40103
llvm-svn: 319680
Resulting library binaries will be named libclang_rt.fuzzer*, and will
be placed in Clang toolchain, allowing redistribution.
Differential Revision: https://reviews.llvm.org/D36908
llvm-svn: 311407
