Add initial support for cargo-fuzz

[cyplo]

• Added support for fuzzing via cargo-fuzz
• Initial run found some small memory leaks - we could run without the check for memleaks, if they are expected ? - see the message near the end of the log file buff.log
• The runs are generally slow - would be curious of the number of operations per second you get ? Would it be because this is a debug build ?

Let me know what you think !

[pkgw]

Awesome, thank you! I also saw the memory leak issue, and will see if I can figure out what the problem is.

Is there a way to run the fuzzer with a specified seed for just a few iterations? As we discussed, we don't want to run the fuzzer seriously as part of the CI, but I'm thinking maybe it would help to do a very short run just to make sure that the infrastructure stays functional.

[cyplo]

Heya !
cargo fuzz relies on libFuzzer internally and can pass its commandline option downstream.
We could use e.g. cargo fuzz run compile -- -max_total_time=60 to run the fuzzer for 60 seconds.
You could also control the seed with -seed there, e.g. cargo fuzz run compile -- -max_total_time=60 -seed=1234 - I would probably recommend starting without controlling the seed, and run it for however much time we think is reasonable on CI - this way we should be able to catch more things in addition to testing whether the fuzzer code still compiles - if that would be something we're interested in. We could even store the intermediate state between such runs for the fuzzer to pick up where it left off - this can sometimes be slow as well though, so up for you to judge.
Hope this helps !

p.s. see https://llvm.org/docs/LibFuzzer.html#options for the list of commandline options

[codecov]

Codecov Report

Merging #315 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #315      +/-   ##
==========================================
- Coverage   39.61%   39.61%   -0.01%     
==========================================
  Files         135      135              
  Lines       59496    59489       -7     
==========================================
- Hits        23569    23565       -4     
+ Misses      35927    35924       -3

Impacted Files	Coverage Δ
src/status/mod.rs	34.78% <0%> (-9.22%)	⬇️
src/io/stdstreams.rs	2.04% <0%> (-5.96%)	⬇️
src/engines/mod.rs	63.96% <0%> (-0.41%)	⬇️
tests/executable.rs	21.59% <0%> (-0.25%)	⬇️
src/errors.rs	37.77% <0%> (ø)	⬆️
xdv/src/lib.rs	0% <0%> (ø)	⬆️
src/engines/spx2html.rs	0% <0%> (ø)	⬆️
tectonic/dpx-truetype.c	0% <0%> (ø)	⬆️
src/io/itarbundle.rs	0% <0%> (ø)	⬆️
tectonic/xetex-ini.c	86.96% <0%> (ø)	⬆️
... and 6 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e186cbb...0f15ef3. Read the comment docs.

[pkgw]

Took me a long time to get back to this, but I've pushed some work aiming to plug the memory leaks. libFuzzer still reports a lot, but valgrind reports many fewer than it did before. Now I can get something to happen that actually looks like the fuzzer might be finding a problem:

INFO: seed corpus: files: 1 min: 70b max: 70b total: 70b rss: 234Mb
#2	pulse  cov: 51882 ft: 50264 lim: 4 exec/s: 0 rss: 516Mb
Slowest unit: 109 s:
artifact_prefix='/home/peter/sw/tex/tectonic/fuzz/artifacts/compile/'; Test unit written to /home/peter/sw/tex/tectonic/fuzz/artifacts/compile/slow-unit-e31a4e9dc7dda926e272e6be28a5595c2305273d
Base64: XGRvY3VtZW50Y2xhc3N7YXJ0aWNsZX0KXGJlZ2lue2RvY3VtZW50fQpIZWxsbywgd29ybGQhClxlbmR7ZG9jdW1lbnR9Cg==
#2	INITED cov: 51882 ft: 50264 corp: 1/70b lim: 4 exec/s: 0 rss: 516Mb
#3	NEW    cov: 51891 ft: 67689 corp: 2/140b lim: 4 exec/s: 0 rss: 546Mb L: 70/70 MS: 1 CopyPart-
AddressSanitizer:DEADLYSIGNAL
=================================================================
==9962==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f89eac9f4ed bp 0x000000000000 sp 0x7fff5ba7b640 T0)
==9962==The signal is caused by a READ memory access.
==9962==Hint: address points to the zero page.
    #0 0x7f89eac9f4ec  (/lib64/libfontconfig.so.1+0x194ec)
    #1 0x55b75c449996  (/home/peter/sw/tex/tectonic/fuzz/target/x86_64-unknown-linux-gnu/debug/compile+0xabd996)
    #2 0x55b75c440d31  (/home/peter/sw/tex/tectonic/fuzz/target/x86_64-unknown-linux-gnu/debug/compile+0xab4d31)
    #3 0x55b75c372702  (/home/peter/sw/tex/tectonic/fuzz/target/x86_64-unknown-linux-gnu/debug/compile+0x9e6702)
    [etc]

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib64/libfontconfig.so.1+0x194ec) 
==9962==ABORTING
MS: 1 ChangeBit-; base unit: 35d50929c46ecfe34fdb12461fe222265b62cda0
0x5c,0x64,0x6f,0x63,0x75,0x6d,0x65,0x6e,0x74,0x63,0x6c,0x61,0x73,0x73,0x7b,0x61,0x72,0x74,0x69,0x63,0x6c,0x65,0x7d,0xa,0x5c,0x62,0x65,0x67,0x69,0x6e,0x7b,0x64,0x6f,0x23,0x21,0xa,0x5c,0x6e,0x74,0x7d,0xa,0x48,0x65,0x6c,0x6c,0x6f,0x2c,0x20,0x77,0x6f,0x72,0x6c,0x64,0x21,0xa,0x5c,0x65,0x6e,0x64,0x7b,0x64,0x6f,0x63,0x75,0x6d,0x65,0x6e,0x74,0x7d,0xa,
\\documentclass{article}\x0a\\begin{do#!\x0a\\nt}\x0aHello, world!\x0a\\end{document}\x0a
artifact_prefix='/home/peter/sw/tex/tectonic/fuzz/artifacts/compile/'; Test unit written to /home/peter/sw/tex/tectonic/fuzz/artifacts/compile/crash-0250a8c2f6c02cb7fa5eef60cfeaae1352d6a7ed
Base64: XGRvY3VtZW50Y2xhc3N7YXJ0aWNsZX0KXGJlZ2lue2RvIyEKXG50fQpIZWxsbywgd29ybGQhClxlbmR7ZG9jdW1lbnR9Cg==

But, if I run Tectonic with that input alone, I don't get a segfault. Hmmm.

[cyplo]

Interesting ! I will take a look as well as soon as I find some time :)

[pkgw]

OK, gonna merge this as-is — the memory leaks can be hunted down later.