| Age | Commit message (Collapse) | Author |
|---|
|
Co-authored-by: Norbert Schneider <norbert.schneider@code-intelligence.com>
Co-authored-by: Peter Samarin <peter.samarin@code-intelligence.com>
|
|
|
|
initial proto2 support
|
|
|
|
Annotations such as `@NotNull` and `@InRange` only apply to particular
types and were silently ignored when applied on other types. This could
lead to subtle issues such as the user (or the author of this commit)
declaring a `@NotNull byte[]` parameter and being surprised to find that
the byte array is sometimes `null` - the annotation applies to the
primitive array component type rather than the array itself.
This commit adds an `@AppliesTo` meta-annotation that can be used to
describe the valid usage sites of an annotation. Valid uses are enforced
both in `ArgumentsMutator` and the `StressTest`.
|
|
|
|
|
|
|
|
|
|
The function wasn't tested and - unsurprisingly - broken.
|
|
|
|
When messages become too complex to exercise fully in unit tests, we
should be adding them to `StressTest` instead.
|
|
The mutator applies to byte, short, int, and long as well as their
wrapper types and is based on fuzztest's `InRange` and `Arbitrary`
implementations for integral types.
Also enhances the statistical tests performed in `StressTest` to more
accurately assert the domain coverage achieved by the mutator.
|
|
Adds more helper functions to `PseudoRandom` for operations commonly
encountered in mutators and not covered well by the standard
`SplittableRandom` API. Also renames methods to be more descriptive.
|
|
While `oneof`s were handled by the existing code, the mutator wasn't
aware of the `oneof`'s state and would thus change it frequently, which
ends up invalidating mutations applied to its other fields.
With this commit, `oneof` fields have their current state tracked and
mutated in 1 out of 100 cases, which allows individual fields to reach
more complicated states.
|
|
In order to support Protobuf messages types that transitively refer to
themselves, the factory for Builder mutators is modified to generate a
single shared mutator instance for a given builder type, which ensures
that recursive structures are represented as finite directed graphs (no
longer just trees) of mutators.
|
|
This requires introducing a new mutable list view as the reflection API
for repeated message fields is subtly different from the one for other
types of fields.
|
|
Support for repeated and recursive message fields will come in follow-up
commits.
|
|
A new `getDebugString` function is introduced that provides a predicate
as an argument with which implementors can check whether they are part
of a cyclic structure (e.g. a self-referential Protobuf message).
This requires making `SerializingMutator` an abstract class so that an
implementation of `toString` can be provided.
|
|
Instead, since MutatorFactories are generally lightweight, they can be
recreated on demand via static `newFactory` calls. This allows them to
maintain instance state without the need for synchronization.
|
|
This has multiple advantages:
* No longer need to reflectively get a Parser for a message.
* Users can request Builders as arguments.
* Allows Builders to be created as needed to support embedded message
fields.
* Reduces MessageMutatorFactory to a single mutateThenMapToImmutable
call.
|
|
This adds:
* asSubclassOrEmpty as a variant of Class#asSubclass;
* an overload of combine that assembles a SerializingInPlaceMutator;
* an overload of MutatorFactory#createInPlaceOrThrow for AnnotatedType.
|
|
|
|
Some `@OptIn`s aren't needed anymore, the other can be replaced with
dedicated annotations that do not require special compiler flags.
|
|
FuzzTargetRunner now interfaces with the rest of code only via the
global FuzzTarget field on FuzzTargetHolder, which contains the resolved
fuzz target method and instance as reflect objects. As a result, the
JUnit extension can directly pass in the objects it has access to
without going through the class name and letting FuzzTargetFinder find
the fuzz test method.
|
|
The JUnit extension already installed the agent manually, so the call to
`AgentInstaller#install` in `FuzzTargetRunner` only took effect when
called from `Driver`.
|
|
If an assertion in `fuzzerTearDown` failed, the test timed out rather
than failing quickly. This is fixed by catching assertion failures and
halting with a non-zero exit code.
|
|
Inputs directory handling was confusing as e.g. Maven doesn't copy over
empty resource directories by default. Instead of relying on that,
always fall back to locating the inputs directory in the source tree and
even try to create it if at least the test resources root is found.
|
|
This commit replaces all direct usages of `System.err` and `System.out`
with equivalent `Log` method calls.
This change is meant to be mostly invisible to users. In some cases the
formatting is changed as we no longer manually wrap lines, which we
never did in a consistent manner. If we want to bring back line breaks,
we should implement this in `Log` instead in a follow-up PR.
In some cases unstructured logging to stdout is moved to stderr.
Fixes FUZZ-480
|
|
Before this commit, `consume` would construct an `Object[]` when a
`Class<?>[]` was requested, leading to `IllegalArgumentExeption`s.
|
|
This makes it possible to run fuzz tests alongside unit tests without
having the instrumentation applied by the agent interfere with unit
tests, e.g. by throwing unexpected exceptions.
|
|
This is used in a follow-up commit to seletively enable hooks in
`@FuzzTest`s but not unit tests during JUnit regression test runs.
Since the additional bytecode for conditional hooks is guarded behind a
property, no performance overhead is expected during fuzzing.
|
|
|
|
This test was disabled accidentally in
727ecb9bdfc25500533e8d4a43d30524b4677fc8.
|
|
|
|
Instead of implementing fuzzing runs as a custom JUnit test engine, this
commit implements it within the JUnit Jupiter platform instead.
The main benefit of this approach is the full and effortless
interoperability with lifecycle hooks such as `@BeforeAll` and
`@AfterAll`. The new implementation is also significantly shorter and
automatically avoids inconsistencies such as
https://github.com/CodeIntelligenceTesting/jazzer/issues/539 and
https://github.com/CodeIntelligenceTesting/jazzer/issues/543.
The new implementation models fuzzing as a single invocation of the
`@ParameterizedTest` used for the regression test with fake arguments
named `Fuzzing...`. The registered `InvocationInterceptor` is then used
to replace the invocation with the actual fuzzing run.
In this way, `@FuzzTest` methods invoke `@BeforeEach` hooks once before
fuzzing starts. Having the invocation represented as a single invocation
parametrized test should make this behavior less surprising.
Fixes #543
|
|
The "driver" and the "agent" used to be separate components of Jazzer
that were written in different languages (C++ and Java), but this is no
longer the case: They are now mostly implemented in Java and deployed as
a single jar. The natural separation into Java packages rather than
top-level directories fits this architecture better.
This commit has been produced by moving the directory contents,
replacing `//(agent|driver)/` with `//`, running `buildifier -r .` and
manually editing non-BUILD occurences (e.g. .bazelrc, format.sh as well
as runfiles paths).
|
