Dmitry Vyukov

Re stdlib integration, if there is an agreement that fuzzing goes in, the first step would be to add testing.F and go tool support for building the binary. We don't...

Is it actually an issue for go-fuzz? "not reporting 100% coverage" should not affect go-fuzz.

Good that you preserved backwards compatibility! Re cumbersome, do you mean the large code template embed in the code? I am not too worried about strictly internal details that we...

> Re goroutine per test, the only reason for this is Skip/Goexit, right? Have you considered panicing and recovering? I think the same could be used for Fail as well.

> If the fuzz function calls recover, then we might never see the panic. This is the same reason that package testing uses a goroutine per invocation plus runtime.Goexit. Recovering...

@DavidVorick Please post this at golang/go#19109

FYI here is a detailed proposal: https://docs.google.com/document/u/1/d/1zXR-TFL3BfnceEAWytV8bnzB2Tfp6EPFinWVJ5V4QC8/pub If you have any comments, post them to https://github.com/golang/go/issues/19109

There are 2 things about the current go-fuzz code: 1. It's overly complex in some places. 2. It's dirty in lots of places. So I am thinking a good way...

Re #65, agree. The current state-of-art in fuzzing seems to be moving in this direction (libfuzzer's protobuf-based mutation, syzkaller). But we again can do the most awesome support for this...

If you see this again, try sending SIGABRT. Then attaching with gdb and sampling stacks of all threads. Also `perf record -p PID` on the process can shed some light...