-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/go: hangs in "found a crash, minimizing..." #46634
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This is a complicated problem, since Go doesn't provide any real way to deal with GC backpressure (see #29696 and the associated issues for background). Unless the worker process actually dies, killing the pipe used for RPC communication, the worker/coordinator has no way of knowing that there is a memory problem. A simple-ish solution would be to just add a timeout to some/all of the RPC calls, so we can just bail out if the worker is taking longer than expected (and we assume it is dead). One question is, if the RPC times out, do we consider that a crash? (i.e. if a fuzz call times out, we copy the input and consider that a crasher). Once we allow for continuous fuzzing (continuing when a crasher is find, rather than immediately exiting), we would need a way of marking a worker process dead, and ideally restarting it so we don't slowly run out of workers. |
This is likely going to be a release blocker for Go 1.18. |
@katiehockman @rolandshoemaker Friendly ping that this issue is marked as a release-blocker for Go 1.18. |
@klauspost are you still able to reproduce this? We've done a lot of fixes with minimization and timeouts, and I am not able to reproduce this locally anymore. |
I'm going to go ahead and close this. Please file a new issue if you experience this issue again. |
What version of Go are you using (
go version
)?What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Ran a fuzz test, that ended up eating up all memory, causing OOMs to happen. This is Windows, so applications just crash and aren't killed by the OS.
Likely one or more of the workers crashed.
What did you expect to see?
The controller printed
found a crash, minimizing...
, but never progressed from there.Left it for about 15 minutes before I killed it.
What did you see instead?
Fuzzer not getting stuck.
The text was updated successfully, but these errors were encountered: