| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
This change only removes libFuzzer tests and CMake machinery,
the source copy temporarily remains at the old location.
Differential Revision: https://reviews.llvm.org/D36980
llvm-svn: 311405
|
|
|
|
|
|
| |
Inline8bitCounters
llvm-svn: 309647
|
|
|
|
| |
llvm-svn: 308075
|
|
|
|
| |
llvm-svn: 307980
|
|
|
|
|
|
| |
to replace elements in the corpus with smaller ones that have the same feature set. Still needs tuning
llvm-svn: 307873
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D35312
llvm-svn: 307824
|
|
|
|
|
|
| |
libFuzzer. This is not fully functional yet, but simple tests work
llvm-svn: 305331
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.
I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.
This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.
Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).
llvm-svn: 304787
|
|
|
|
|
|
| |
that size. This will potentially make libFuzzer more sensitive on targets with lots of signals
llvm-svn: 298671
|
|
|
|
| |
llvm-svn: 298654
|
|
|
|
|
|
| |
-save_coverage_summary/-load_coverage_summary. This is still WIP, the documentation will come later if these flags survive
llvm-svn: 298548
|
|
|
|
| |
llvm-svn: 290039
|
|
|
|
|
|
| |
(https://github.com/google/sanitizers/issues/722). This is a first experimental variant that needs some more testing, thus not yet adding a lit test (but there are unit tests).
llvm-svn: 289166
|
|
|
|
|
|
| |
ways to mutate a binary integer
llvm-svn: 284909
|
|
|
|
|
|
| |
created by the current process
llvm-svn: 283682
|
|
|
|
| |
llvm-svn: 283409
|
|
|
|
| |
llvm-svn: 282224
|
|
|
|
|
|
| |
> MaxSize, fix sha1 in corpus stats; various refactorings
llvm-svn: 282129
|
|
|
|
| |
llvm-svn: 282121
|
|
|
|
|
|
| |
unit from the corpus, use the stored one.
llvm-svn: 282115
|
|
|
|
| |
llvm-svn: 282044
|
|
|
|
|
|
| |
from r278970
llvm-svn: 278982
|
|
|
|
| |
llvm-svn: 278950
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New mutation: InsertRepeatedBytes.
Updated mutation: EraseByte => EraseBytes.
This helps https://github.com/google/sanitizers/issues/710
where libFuzzer was not able to find a known bug.
Now it finds it in minutes.
Hopefully, the change is general enough to help other targets.
llvm-svn: 278687
|
|
|
|
| |
llvm-svn: 275648
|
|
|
|
|
|
|
|
| |
Summary: It also fixes a bug, when first random might not be ascii.
Differential Revision: http://reviews.llvm.org/D21573
llvm-svn: 273611
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ``FuzzerMutate.ShuffleBytes2`` unit test was failing on
OSX due to the implementation of ``std::random_shuffle()``
being different between libcxx and libstdc++.
@kcc has decided (see http://reviews.llvm.org/D21218) it is acceptable
for there to be different mutation behavior on different platforms so
this commit just adjusts the test to perform the minimum number of
iterations (that is a power of 2) to see all the mutations the unit test
is looking for.
Differential Revision: http://reviews.llvm.org/D21359
llvm-svn: 272743
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the following unit tests:
FuzzerDictionary.ParseOneDictionaryEntry
FuzzerDictionary.ParseDictionaryFile
The issue appears to be mixing non-ASan-ified code (LibFuzzer) and
ASan-ified code (the unittest) as the tests would pass fine if
everything was built with ASan enabled.
I believe the issue is that different implementations of std::vector<>
are being used in LibFuzzer and outside LibFuzzer (in the unittests).
For Libcxx (I've not seen the issue manifest for libstdc++) we can disable
the ASanified std::vector<> by definining the ``_LIBCPP_HAS_NO_ASAN`` macro.
Doing this fixes the tests on OSX.
Differential Revision: http://reviews.llvm.org/D21049
llvm-svn: 272374
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes linking problems on OSX.
Unfortunately it turns out we need to use an instance of the
``fuzzer::ExternalFunctions`` object in several places so this
commit also replaces all instances with a single global instance.
It also turns out initializing a global ``fuzzer::ExternalFunctions``
before main is entered (i.e. letting the object be initialised by the
global initializers) is not safe (on OSX the call to ``Printf()`` in the
CTOR crashes if it is called from a global initializer) so we instead
have a global ``fuzzer::ExternalFunctions*`` and initialize it inside
``FuzzerDriver()``.
Multiple unit tests depend also depend on the
``fuzzer::ExternalFunctions*`` global so a ``main()`` function has been
added that initializes it before running any tests.
Differential Revision: http://reviews.llvm.org/D20943
llvm-svn: 272072
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20641
llvm-svn: 270755
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20301
llvm-svn: 270632
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18705
llvm-svn: 265174
|
|
|
|
| |
llvm-svn: 260798
|
|
|
|
| |
llvm-svn: 260797
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix the issue with the most recently discovered unit receiving much less attention.
Note: this is the second attempt (prev: r258473). Now, libc++ build is fixed.
Reviewers: aizatsky, kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16487
llvm-svn: 258571
|
|
|
|
|
|
|
|
| |
Reviewers: kcc
Differential Revision: http://reviews.llvm.org/D16441
llvm-svn: 258479
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix the issue with the most recently discovered unit receiving much less attention.
Note: I had to change the seed for one test to make it pass. Alternatively,
the number of runs could be increased. I believe that the average time of
'foo' discovery is not increased, just seed=1 was particularly convenient
for the previous PRNG scheme used.
Reviewers: aizatsky, kcc
Subscribers: llvm-commits, kcc
Differential Revision: http://reviews.llvm.org/D16419
llvm-svn: 258473
|
|
|
|
|
|
| |
to avoid memory allocations on hot path
llvm-svn: 257985
|
|
|
|
|
|
| |
dictionary entries were successful
llvm-svn: 257736
|
|
|
|
| |
llvm-svn: 257013
|
|
|
|
| |
llvm-svn: 256081
|
|
|
|
|
|
| |
Since libFuzzer should not depend on anything, just re-implement base64 encoder. PR25746
llvm-svn: 254784
|
|
|
|
| |
llvm-svn: 247027
|
|
|
|
| |
llvm-svn: 246825
|
|
|
|
|
|
| |
a class. NFC
llvm-svn: 246808
|
|
|
|
| |
llvm-svn: 246800
|
|
|
|
| |
llvm-svn: 244188
|
|
|
|
| |
llvm-svn: 243818
|
|
|
|
| |
llvm-svn: 243817
|
|
|
|
| |
llvm-svn: 243078
|