Corey Farwell

Also the Rust + libfuzzer integration is working for me for other crates, just not this one.

My understanding is that the timeout is for a test run for a _single_ generated input. As opposed the to total lifespan of the fuzzer which will test an indefinite...

AFL's parallel fuzzing story is a little more involved than just turning on a flag, unfortunately :-/ https://github.com/mirrorer/afl/blob/master/docs/parallel_fuzzing.txt

The main challenge here is figuring out how to gather statistics from the fuzzers. Ideally, for each fuzz target, we'd output in HTML: * `` * `` * `` *...

For reference, `cargo run -- continuous` isn't in `master` yet, it's in [this pull request](https://github.com/rust-fuzz/targets/pull/103) though

This is blocked on https://github.com/rust-fuzz/targets/issues/66

My main hesitation here is that it could blow up the side of the git object database as some corpus files can get pretty large. This could be FUD though.

If I run it again, it finds: ``` ==29444==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdca958968 at pc 0x7f2c9301c3fe bp 0x7ffdca958930 sp 0x7ffdca958928 ACCESS of size 0 at 0x7ffdca958968 thread T0 #0...

https://github.com/rust-fuzz/targets/pull/35 is the target

Here's a gdb run: ``` (gdb) r Starting program: /home/corey/dev/targets/target/debug/read [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x000055555567c259 in core::slice::{{impl}}::position (self=0x7fffffff9040,...