Tony Allevato 27d8bb9f90 Inline the bytecode string into the `_NameMap.init(bytecode:)` call. (#1804) 9 months ago
..
FailCases b842955fa4 Range check timestamps on all parsing paths. 1 year ago
Sources 27d8bb9f90 Inline the bytecode string into the `_NameMap.init(bytecode:)` call. (#1804) 9 months ago
Tests ac8da77c93 Run `swift-format -p -r -i .` 1 year ago
.gitignore ffc51fff03 Add another ignore. 5 years ago
FuzzAsyncMessageSequence.dict 3a381048e0 Update the fuzz dictionaries. 1 year ago
FuzzBinary.dict 3a381048e0 Update the fuzz dictionaries. 1 year ago
FuzzBinaryDelimited.dict 3a381048e0 Update the fuzz dictionaries. 1 year ago
FuzzJSON.dict 3a381048e0 Update the fuzz dictionaries. 1 year ago
FuzzTextFormat.dict 3a381048e0 Update the fuzz dictionaries. 1 year ago
Package.swift e41d3f0c93 Drop Swift 5.9 (#1775) 10 months ago
README.md e1943f3e70 Add dictionaries for help steer the fuzz testing. 4 years ago
do_build.sh 22a71b76db Fix options needing multiple bytes, add tests. 1 year ago
make_FuzzBinary_dict 5ec1e8703f Add a dict to help steer binary fuzzing. 4 years ago

README.md

FuzzTesting

This subpackage build binaries to be use with Fuzz testing.

NOTE: The Swift toolchain distributed with Xcode do not include the fuzzing support, so for macOS, one needs to install the swift.org toolchain and use that instead.

To build on macOS:

xcrun \
  --toolchain swift \
  swift build -c debug -Xswiftc -sanitize=fuzzer,address -Xswiftc -parse-as-library

To build on linux:

swift build -c debug -Xswiftc -sanitize=fuzzer,address -Xswiftc -parse-as-library

Then the binaries will be found in .build/debug.

Note: You can also use -c release to build/test in release instead as that could find different issues.

In this directory you will also find a do_build.sh script. By default it builds for both debug and release. You can also pass --run-regressions to have it run the the build against the previous failcases to check for regressions.

When issues are found:

  1. Make sure you add a file to FailCases subdirectory so regressions can easily be watched for. The GitHub workflow runs against there.

  2. Consider adding them to Tests/SwiftProtobufTests/Test_FuzzTests.swift, this help in debugging while working on the failure, but also provides yet another way to ensure things don't regress and if they do, it is much easier to immediately debug the issue.

A note about memory issues, the address sanitizer is enabled in the fuzz tests and in that context can find different things that what are found running the unittests with the address sanitizer. So having test cases in both places can be needed to help ensure something is less likely to regress.

There are dictionaries to help steer the fuzzing of JSON and TextFormat, to run with them, just add -dict=FuzzJSON.dict or -dict=FuzzTextFormat.dict to the invocation of the fuzz binary.