Change https://golang.org/cl/352892 mentions this issue: internal/fuzz: disconnect stdout and stderr from the worker

Thank you for the quick turnaround!

@mvdan can you clarify whether this is happening every time you run this, or if it's just a flaky issue that you run into? My suspicion is that there's just some extraneous FAIL message coming from a worker that was interrupted, which is what you're seeing, but it's hard to be sure.

The number of FAIL lines varies each time. I have 16 logical CPU cores, so the fuzzer launches 16 workers. Sometimes I see just a few FAIL lines, some other times I see over a dozen.

I don't think I've ever seen zero FAIL lines after a ^C. I just tried six times in a row, and it always showed at least a handful each time. So it's definitely not a rare occurrence for me.

I was just able to reproduce this locally even with the change that I mailed. So there is something else going on. (At best, my change will simply decrease the number of "FAIL" lines that occur, which doesn't really fix the issue)

I am still not sure how we are going to fix this, but I've at least narrowed it down to https://github.com/golang/go/blob/master/src/cmd/go/internal/test/test.go#L1797. When I run this locally with my patch, this is the FAIL line that is being printed (i.e. the one coming from the main go command process). Will look into how to avoid this.

Edit: the merged CL should fix the issue. I went ahead and disabled printExitStatus when -fuzz is provided.