A user who is working on adding a new project to OSS-Fuzz pointed out that our docs aren't clear in this regard. It's pretty clear that for the OSS-Fuzz builder projects should use given CC, CFLAGS, and so on, but how should their standalone fuzzing config look like?

The example project has some guidance in comments

https://github.com/google/oss-fuzz/blob/51dd9a02cb2a87dd9a634da61f967d97

I was recently attempting to test a bug that seemed to only manifest when it encountered emoji (and not necessarily other high-unicode codepoints). I figured that strategies.text() would just naturally include some emoji, but I've found that the following tests only fail about 25% of the time (clearing .hypothesis between runs):

from hypothesis import given, settings
from hypo

There are two columns whose meaning are unclear to me.

Cover - this is not a percent value, so a description would help to interpret this.

Restarts - it’s unclear to me what causes the fuzzer to restart. There is an indication that you should aim to restart 1/1000 but it’s not clear how to influence this.

The dashboard app doesn't have much documentation - it took me a while to figure out I needed to install the Google Cloud SDK to do anything with it. It would be nice to have some basic setup instructions documented.

I spent an hour right now trying to debug error connecting to pipe on test run without afl-fuzz. It occured that I forgot the -debug option. While the whole thing is kinda obvious, if you need test run then you shouldn't forget the -debug, a suggestion about it on pipe error would've been very helpful.

What I propose is to edit error message so it would be `error connecting to pipe (did y

fast-check is a very nice library. It would be even better if we could use it with Facebook's ReasonML instead of Typescript!

It might be possible to use https://github.com/rrdelaney/ReasonablyTyped to make the conversion easier.

So while I was debugging another issue, I came along the enormous list of parameters in the Session class. I feel that some of them should be moved to more appropriate locations, and I'd argue that this should be a breaking change. Benefits: better documentation, easier to understand.

In particular:

• ignore_connection_reset, ignore_connection_aborted, `ignore_connection_issues_when_sendin

As we've found in rust-lang/rust#36705, jemalloc has abysmal fork performance in some kernel configurations, notably on recent Ubuntu versions.

Even on good configurations system default allocator has about 20% better fork performance than jemalloc.

This can be done in documentation, by adding the 2 lines described in https://doc.rust-lang.org/nightly/book/custom-alloc

I've created some example code and scripts in the wiki, they could be in the repo and either useful documentation or tests for the testsuite.

https://github.com/googleprojectzero/halfempty/wiki/Examples

Yaourt is dangerous, as it executes the PKGBUILD instead of letting the user view it before executing. Pacaur should be used instead.

References:
Arch Wiki
Reddit explanation

Section 3.4 of the paper describes using gradient descent with a 2-point method for computing the gradient vector. This basically involves doing O(d) function calls to find the approximate gradient then doing a small number of calls to move in that direction. There is a long history of Derivative free Optimization Methods, that try to make each function evaluation do some of both. For example so

This is something that hasn't been super clear to me, and I haven't really seen it discussed anywhere ever.

The corpus

• can end up getting sizable (see also #163)
• often isn't human readable

Committing it to the project-being-fuzzed's repo seems like it could add a bunch of git overhead and even make merges difficult.

But, it is needed to "pick up where you left off" when doing time

Each fuzzer executor (frontend) implements populate_stats method that changes fuzzer-specific output information to the uniform one. That is, it's populate self.stats dictionary.

Currently only AFL provides reasonable amount of runtime informations that are easily accessible and therefore used by the deepstate. Also we scan CRASH_DIR and count amount of crashes found. But other tools ne