FreeType is a freely available software library to render fonts.
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:
OSS-Fuzz has two entry points. The process is currently split into two parts to allow for some hacking in OSS-Fuzz's
Travis CI calls
run-travis-ci.sh, which supports two different rows/lanes:
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.
As stated above, debugging sessions usually start like this:
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
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.
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
--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 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
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
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