tree: 5c9ed8f9790714289e1a75e8beb9b930b77c2cce [path history] [tgz]
  1. build/
  2. travis-ci/
  3. build-fuzzers.sh
  4. cleanup.sh
  5. custom-build.sh
  6. prepare-oss-fuzz.sh
  7. README.md
  8. run-travis-ci.sh
fuzzing/scripts/README.md

License: GPL v2 Build Status

FreeType

https://www.freetype.org

FreeType is a freely available software library to render fonts.

Scripts

The scripts in this folder are designed to build (and prepare) the fuzz targets in (and for) various scenarios. At the moment, there are three main stakeholders:

Debugging the Fuzz Targets

This section demonstrates a few aspects of working with this subproject as a developer when debugging FreeType. Debugging other submodules or the fuzz targets themselves works similarly but has a few edge cases that have to be taken care of.

Building the Fuzz Targets

As stated above, debugging sessions usually start like this:

$ ./custom-build.sh

After choosing all settings, the script takes care of initialising/resetting relevant build systems before it starts the build process. The result of this process is a test driver artefact in /fuzzing/build/bin.

Due to reasons regarding caching specific builds (and running different setups in parallel), the name of the test driver artefact is based on chosen settings. To keep simple things simple, /fuzzing/build/bin/driver will always link to the most recently built driver.

More details in regard to using the test driver can be obtained from simply questioning its usage message:

$ ./driver --help

The same holds true for the build script:

$ ./custom-build.sh --help

One specific option of the build script shall be highlighted here:

$ ./custom-build.sh --rebuild

--rebuild only make sense when used after a completely successful build without that option. Essentially, what it does is to call make in every used build system to trigger a rebuild of the test driver without resetting anything. That way, rebuilding the test driver is a matter of seconds instead of it taking up to a few minutes. Mind, however, that using --rebuild after an unsuccessful initial build results in undefined behaviour and, most certainly, does not accomplish meaningful things.

Making Changes to FreeType

FreeType lives in /external/freetype2 as a read-only copy of the repository. Every build script always tries to pull the latest version of FreeType. Hence, calling ./custom-build.sh ensures that the test driver is built with FreeType's upstream.

When debugging FreeType, it is advisable to make changes to /external/freetype2 as these changes will be detected and used by ./custom-build.sh --rebuild. BEWARE: calling ./custom-build.sh (without --rebuild) resets all changes made to that submodule. Thus, it is good practice to save changes in the form of a patch before rebuilding the test target:

$ cd /external/freetype2
$ git diff >~/my.patch

Once a bug is fixed, this patch can be applied to a writable copy of FreeType's repository.

Valgrind

Valgrind can be very helpful when debugging FreeType and it works out of the box:

$ valgrind ./driver --foo ~/foo

The best performance and the best results can be achieved when using valgrind without sanitizers and also without glog.

Glog

Google's Logging Module can be activated through custom-build.sh. If activated, it will write all logging messages to a temporary file on the disk and, additionally, print error logs to stderr. Glog will only print all logging messages (especially info) to stderr if advised per environment variable:

$ GLOG_logtostderr=1 ./driver --foo ~/foo

Further settings can be found here: http://rpg.ifi.uzh.ch/docs/glog.html