commit | 0fdfd1aa286054cbf42bbf93006404caa2b827b8 | [log] [tgz] |
---|---|---|
author | FuzzTest Team <fuzztest@google.com> | Mon Nov 21 12:48:07 2022 -0800 |
committer | Copybara-Service <copybara-worker@google.com> | Mon Nov 21 12:48:34 2022 -0800 |
tree | 6774c0b889b65a95e9f78ed5d5b1c8e7380dc067 | |
parent | 22246df7f22fc20a6d0657123e549686550d2d60 [diff] |
FuzzTest: make use of SA_ONSTACK flag for signal handlers For programs with Go threads present, signal handlers must be initialized with the `SA_ONSTACK` flag due to Go threads inherently having small stacks [0]. This flag ensures that a dedicated stack is used during the execution of a signal handler. Failing to initialize signal handlers with `SA_ONSTACK` results in the abnormal termination of the program in the instance that a signal is received. FTR, we're making use of FuzzTest to test both our C++ and Go code. We use `cgo` as a mechanism for exposing Go functions to C++ test code and hence Go threads being present in the C++ test binary. Apart from an increased memory footprint due to the kernel having to install a dedicated stack region for the signal handler to run in, I don't immediately foresee there being any other problems using the SA_ONSTACK by default. [0] https://pkg.go.dev/os/signal#hdr-Go_programs_that_use_cgo_or_SWIG PiperOrigin-RevId: 490049359
FuzzTest is a C++ testing framework for writing and executing fuzz tests, which are property-based tests executed using coverage-guided fuzzing under the hood. Fuzz tests are like regular unit tests, but more generic and more powerful. Instead of saying: “for this specific input, we expect this specific output”, we can say: “for these types of input, we expect this generic property to be true”. For example:
void MyApiAlwaysSucceedsOnPositiveIntegers(int i) { bool success = MyApi(i); EXPECT_TRUE(success); } FUZZ_TEST(MyApiTest, MyApiAlwaysSucceedsOnPositiveIntegers) .WithDomains(/*i:*/fuzztest::Positive<int>());
It is our latest fuzz testing technology and the successor of previously used fuzzing tools, such as libFuzzer. It allows you to write powerful fuzz tests more easily than with previously used fuzz targets. You can use it together with GoogleTest, or other unit testing frameworks, allowing you to write fuzz test side by side with regular unit tests, and just as easily.
It is a first-of-its-kind tool that bridges the gap between fuzzing and property-based testing, as it is both:
FuzzTest is for everyone who writes C++ code. (Currently, only C++ is supported.) Fuzz testing is a proven testing technique that has found tens of thousands of bugs. With the FuzzTest framework writing these tests becomes a breeze. Because fuzz tests are more generic, they are more powerful than regular unit tests. They can find tricky edge cases automatically for us, edge cases that most likely we would never think of.
You can write fuzz tests as easily as you write unit tests using GoogleTest for example. Simply use the FUZZ_TEST
macro like you would use GoogleTest's TEST
macro.
At Google, FuzzTest is widely used and software engineers love it. It has replaced the old style of writing fuzz targets.
To get started, read the Quickstart with Bazel, then take a look at the Overview and the Codelab.
Once you have a high level understanding about fuzz tests, consider reading the rest of the documentation, including the:
If you have a question or encounter a bug, please file an issue on GitHub.