Tracking issue: support go-fuzz

[Dor1s]

We were thinking about this for a while, now started to make some progress.

There are two modes of go-fuzz:

1. "native" mode (i.e. using go-fuzz): https://github.com/dvyukov/go-fuzz

2. libFuzzer-compatible mode: https://github.com/dvyukov/go-fuzz#libfuzzer-support -- requires certain build actions, but the resulting binary has libFuzzer interface

Part 2) is easier to integrate, as we can rely on the existing libFuzzer fuzzing engine integration. That's what we start from.

[Dor1s]

Related PRs:

1. Initial golang stacktrace support: Stack Analyzer: add parsing for Golang stacktraces (#265). #827

2. Follow up for some standard stackframes: Clarify the regex for runtime.raise stack frame and fix a test. #853

3. Follow up for even better parsing and unknown crash type handling: Stack analyzer: better parsing for Golang stacktraces. #854

[Dor1s]

Hey @dvyukov, when you get a chance, could you please tell us more about the advantages the native go-fuzz has over the libFuzzer-compatible mode? Is that something CF must support eventually, in your opinion? Thanks!

[Dor1s]

A relevant discussion about code coverage for Go is happening in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16549#c2

[dvyukov]

Hey @dvyukov, when you get a chance, could you please tell us more about the advantages the native go-fuzz has over the libFuzzer-compatible mode? Is that something CF must support eventually, in your opinion? Thanks!

• @josharian @thepudds

I can think of 2 things (besides the fact that obviously everybody thinks that his fuzzing engine is the best one :)):

1. We don't have comparison instrumentation in libfuzzer mode. Theoretically this is doable but as far as I understand libfuzzer does not have an interface to inject them at the moment.
2. Most likely the 2 modes will find different subsets of bugs (significantly overlapping, but still there will be some unique ones). Now I suspect lots of users will use the native go-fuzz locally and then oss-fuzz will not be in the best light when it will appear that it somehow misses easy to find bugs. Users may not understand the internal mechanics, for them it will look like they are finding some bugs very quickly locally but oss-fuzz is not reporting them.

[Dor1s]

TODO from https://github.com/google/clusterfuzz/pull/1151/files#diff-64146a33e026ed0a850f80210c83b508R269

we currently do not distinguish startup crash vs corpus crash for Go fuzz targets in the stats

[inferno-chromium]

This is done.