[libfuzzer] add test of cov file-id in control file

There is test for ft file-id in control file, but no test for cov line.
Without the test, a invalid cov file-id would cause crash.

Reviewed By: v

[libfuzzer] add test of cov file-id in control file

There is test for ft file-id in control file, but no test for cov line.
Without the test, a invalid cov file-id would cause crash.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D145672

show more ...

Greedy set cover implementation of `Merger::Merge`

Extend the existing single-pass algorithm for `Merger::Merge` with an algorithm that gives better results. This new implementation can be used with

Greedy set cover implementation of `Merger::Merge`

Extend the existing single-pass algorithm for `Merger::Merge` with an algorithm that gives better results. This new implementation can be used with a new **set_cover_merge=1** flag.

This greedy set cover implementation gives a substantially smaller final corpus (40%-80% less testcases) while preserving the same features/coverage. At the same time, the execution time penalty is not that significant (+50% for ~1M corpus files and far less for smaller corpora). These results were obtained by comparing several targets with varying size corpora.

Change `Merger::CrashResistantMergeInternalStep` to collect all features from each file and not just unique ones. This is needed for the set cover algorithm to work correctly. The implementation of the algorithm in `Merger::SetCoverMerge` uses a bitvector to store features that are covered by a file while performing the pass. Collisions while indexing the bitvector are ignored similarly to the fuzzer.

Reviewed By: morehouse

Differential Revision: https://reviews.llvm.org/D105284

show more ...

[compiler-rt] NFC: Fix trivial typo

Reviewed By: xgupta

Differential Revision: https://reviews.llvm.org/D77457

[libFuzzer] replace Vector/Set with std::vector/std::set. The custom names are not required any more since we now build with a private version of libc++. Fix some of the 81+ character lines. Mechanic

[libFuzzer] replace Vector/Set with std::vector/std::set. The custom names are not required any more since we now build with a private version of libc++. Fix some of the 81+ character lines. Mechanical change, NFC expected.

[libFuzzer] replace Vector/Set with std::vector/std::set.

Reviewed By: morehouse

Differential Revision: https://reviews.llvm.org/D107374

show more ...

[crt][fuzzer] Fix up various numeric conversions

Attempting to build a standalone libFuzzer in Fuchsia's default toolchain for the purpose of cross-compiling the unit tests revealed a number of not

[crt][fuzzer] Fix up various numeric conversions

Attempting to build a standalone libFuzzer in Fuchsia's default toolchain for the purpose of cross-compiling the unit tests revealed a number of not-quite-proper type conversions. Fuchsia's toolchain include `-std=c++17` and `-Werror`, among others, leading to many errors like `-Wshorten-64-to-32`, `-Wimplicit-float-conversion`, etc.

Most of these have been addressed by simply making the conversion explicit with a `static_cast`. These typically fell into one of two categories: 1) conversions between types where high precision isn't critical, e.g. the "energy" calculations for `InputInfo`, and 2) conversions where the values will never reach the bits being truncated, e.g. `DftTimeInSeconds` is not going to exceed 136 years.

The major exception to this is the number of features: there are several places that treat features as `size_t`, and others as `uint32_t`. This change makes the decision to cap the features at 32 bits. The maximum value of a feature as produced by `TracePC::CollectFeatures` is roughly:
(NumPCsInPCTables + ValueBitMap::kMapSizeInBits + ExtraCountersBegin() - ExtraCountersEnd() + log2(SIZE_MAX)) * 8

It's conceivable for extremely large targets and/or extra counters that this limit could be reached. This shouldn't break fuzzing, but it will cause certain features to collide and lower the fuzzers overall precision. To address this, this change adds a warning to TracePC::PrintModuleInfo about excessive feature size if it is detected, and recommends refactoring the fuzzer into several smaller ones.

Reviewed By: morehouse

Differential Revision: https://reviews.llvm.org/D97992

show more ...

Expand unit tests for fuzzer::Merger

This change adds additional unit tests for fuzzer::Merger::Parse and fuzzer::Merger::Merge in anticipation of additional changes to the merge control file format

Expand unit tests for fuzzer::Merger

This change adds additional unit tests for fuzzer::Merger::Parse and fuzzer::Merger::Merge in anticipation of additional changes to the merge control file format to support cross-process fuzzing.

It modifies the parameter handling of Merge slightly in order to make NewFeatures and NewCov consistent with NewFiles; namely, Merge *replaces* the contents of these output parameters rather than accumulating them (thereby fixing a buggy return value).

This is change 1 of (at least) 18 for cross-process fuzzing support.

Reviewed By: morehouse

Differential Revision: https://reviews.llvm.org/D94506

show more ...

[libFuzzer] Make -merge=1 to reuse coverage information from the control file.

Summary:
This change allows to perform corpus merging in two steps. This is useful when
the user wants to address the f

[libFuzzer] Make -merge=1 to reuse coverage information from the control file.

Summary:
This change allows to perform corpus merging in two steps. This is useful when
the user wants to address the following two points simultaneously:

1) Get trustworthy incremental stats for the coverage and corpus size changes
when adding new corpus units.
2) Make sure the shorter units will be preferred when two or more units give the
same unique signal (equivalent to the `REDUCE` logic).

This solution was brainstormed together with @kcc, hopefully it looks good to
the other people too. The proposed use case scenario:

1) We have a `fuzz_target` binary and `existing_corpus` directory.
2) We do fuzzing and write new units into the `new_corpus` directory.
3) We want to merge the new corpus into the existing corpus and satisfy the
points mentioned above.
4) We create an empty directory `merged_corpus` and run the first merge step:

`
./fuzz_target -merge=1 -merge_control_file=MCF ./merged_corpus ./existing_corpus
`

this provides the initial stats for `existing_corpus`, e.g. from the output:

`
MERGE-OUTER: 3 new files with 11 new features added; 11 new coverage edges
`

5) We recreate `merged_corpus` directory and run the second merge step:

`
./fuzz_target -merge=1 -merge_control_file=MCF ./merged_corpus ./existing_corpus ./new_corpus
`

this provides the final stats for the merged corpus, e.g. from the output:

`
MERGE-OUTER: 6 new files with 14 new features added; 14 new coverage edges
`

Alternative solutions to this approach are:

A) Store precise coverage information for every unit (not only unique signal).
B) Execute the same two steps without reusing the control file.

Either of these would be suboptimal as it would impose an extra disk or CPU load
respectively, which is bad given the quadratic complexity in the worst case.

Tested on Linux, Mac, Windows.

Reviewers: morehouse, metzman, hctim, kcc

Reviewed By: morehouse

Subscribers: JDevlieghere, delcypher, mgrang, #sanitizers, llvm-commits, kcc

Tags: #llvm, #sanitizers

Differential Revision: https://reviews.llvm.org/D66107

llvm-svn: 371620

show more ...

[libFuzzer] Merge: print feature coverage number as well.

Summary:
feature coverage is a useful signal that is available during the merge
process, but was not printed previously.

Output example:

`

[libFuzzer] Merge: print feature coverage number as well.

Summary:
feature coverage is a useful signal that is available during the merge
process, but was not printed previously.

Output example:

```
$ ./fuzzer -use_value_profile=1 -merge=1 new_corpus/ seed_corpus/
INFO: Seed: 1676551929
INFO: Loaded 1 modules (2380 inline 8-bit counters): 2380 [0x90d180, 0x90dacc),
INFO: Loaded 1 PC tables (2380 PCs): 2380 [0x684018,0x68d4d8),
MERGE-OUTER: 180 files, 78 in the initial corpus
MERGE-OUTER: attempt 1
INFO: Seed: 1676574577
INFO: Loaded 1 modules (2380 inline 8-bit counters): 2380 [0x90d180, 0x90dacc),
INFO: Loaded 1 PC tables (2380 PCs): 2380 [0x684018,0x68d4d8),
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 1048576 bytes
MERGE-INNER: using the control file '/tmp/libFuzzerTemp.111754.txt'
MERGE-INNER: 180 total files; 0 processed earlier; will process 180 files now
#1 pulse cov: 134 ft: 330 exec/s: 0 rss: 37Mb
#2 pulse cov: 142 ft: 462 exec/s: 0 rss: 38Mb
#4 pulse cov: 152 ft: 651 exec/s: 0 rss: 38Mb
#8 pulse cov: 152 ft: 943 exec/s: 0 rss: 38Mb
#16 pulse cov: 520 ft: 2783 exec/s: 0 rss: 39Mb
#32 pulse cov: 552 ft: 3280 exec/s: 0 rss: 41Mb
#64 pulse cov: 576 ft: 3641 exec/s: 0 rss: 50Mb
#78 LOADED cov: 602 ft: 3936 exec/s: 0 rss: 88Mb
#128 pulse cov: 611 ft: 3996 exec/s: 0 rss: 93Mb
#180 DONE cov: 611 ft: 4016 exec/s: 0 rss: 155Mb
MERGE-OUTER: succesfull in 1 attempt(s)
MERGE-OUTER: the control file has 39741 bytes
MERGE-OUTER: consumed 0Mb (37Mb rss) to parse the control file
MERGE-OUTER: 9 new files with 80 new features added; 9 new coverage edges
```

Reviewers: hctim, morehouse

Reviewed By: morehouse

Subscribers: delcypher, #sanitizers, llvm-commits, kcc

Tags: #llvm, #sanitizers

Differential Revision: https://reviews.llvm.org/D66030

llvm-svn: 368617

show more ...

[libFuzzer] Merge: print stats after reading the output corpus dir.

Summary:
The purpose is to be able to extract the number of new edges added to
the original (i.e. output) corpus directory after d

[libFuzzer] Merge: print stats after reading the output corpus dir.

Summary:
The purpose is to be able to extract the number of new edges added to
the original (i.e. output) corpus directory after doing the merge. Use case
example: in ClusterFuzz, we do merge after every fuzzing session, to avoid
uploading too many corpus files, and we also record coverage stats at that
point. Having a separate line indicating stats after reading the initial output
corpus directory would make the stats extraction easier for both humans and
parsing scripts.

Context: https://github.com/google/clusterfuzz/issues/802.

Reviewers: morehouse, hctim

Reviewed By: hctim

Subscribers: delcypher, #sanitizers, llvm-commits, kcc

Tags: #llvm, #sanitizers

Differential Revision: https://reviews.llvm.org/D66020

llvm-svn: 368461

show more ...

[libFuzzer] automatically collect the data flow trace (DFT) in the fork mode if -collect_data_flow= is given

llvm-svn: 361448

[libFuzzer][Windows] Port fork mode to Windows

Summary:
Port libFuzzer's fork mode to Windows.
Implement Windows versions of MkDir, RmDir, and IterateDirRecursive to do this.
Don't print error messa

[libFuzzer][Windows] Port fork mode to Windows

Summary:
Port libFuzzer's fork mode to Windows.
Implement Windows versions of MkDir, RmDir, and IterateDirRecursive to do this.
Don't print error messages under new normal uses of FileSize (on a non-existent file).
Implement portable way of piping output to /dev/null.
Fix test for Windows and comment fork-sigusr.test on why it won't be ported to Win.

Reviewers: zturner

Reviewed By: zturner

Subscribers: kcc, zturner, jdoerfert, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D58513

llvm-svn: 355019

show more ...

[libFuzzer] print new functions as they are discovered in the fork mode

llvm-svn: 354092

[libFuzzer] fix the unit tests

llvm-svn: 354088

[libFuzzer] when doing the merge, keep track of the coveraged edges, not just features

llvm-svn: 354087

[libFuzzer] when doing the merge, keep track of the coveraged edges, not just features

llvm-svn: 354076

[libFuzzer] a bit of refactoring of the fork mode

llvm-svn: 353910

[libFuzzer] make the fork mode less verbose

llvm-svn: 353794

[libFuzzer] teach the fork mode to ignore OOMs and timeouts

llvm-svn: 353792

[libFuzzer] extend the -fork=1 functionality. Still not fully usable, but good enough for the first unit test

llvm-svn: 353775

[libFuzzer] more refactoring; change some of the exit codes (timeout, OOM, interrupt) so that the parent process can distinguish those

llvm-svn: 353584

[libFuzzer] refactor the merging code, NFC

llvm-svn: 353576

[libFuzzer] remove two unused experimental flags

llvm-svn: 353573

[libFuzzer] introduce an experimental mode -fork=1, where fuzzing happens in a subprocess (still running multiple inputs per process), thus making the fuzzing more resilient to timeouts and OOMs. Thi

[libFuzzer] introduce an experimental mode -fork=1, where fuzzing happens in a subprocess (still running multiple inputs per process), thus making the fuzzing more resilient to timeouts and OOMs. This is just a skeleton of the code, and some associated refactoring, not a fully working feature yet.

llvm-svn: 353570

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Revert "[compiler-rt] Change std::sort to llvm::sort in response to r327219"

This reverts commit 2ee210e1963e03aacc0f71c50e4994bb5c66586e.

llvm-svn: 327936