Proposal Details
The fuzz worker (
|
timer := time.AfterFunc(60*time.Second, func() { |
) currently hardcodes a timeout of 10s per runner. In a recent unrelated commit (
https://go-review.googlesource.com/c/go/+/707355?tab=comments) this was updated to 60s.
I have a few fuzzers that sometimes time out within the 10s, so I appreciate the update to 60, but I think the clean way of doing this is not to have a hardcoded constant laying around in the code that gets updated whenever maintainers run into the same issues that users do, but to make it configureable.
There was already a proposal for --fuzz.timeout here: #46220 which was closed by a PR that doesn't really address the issue afaict. I agree that overloading --timeout isn't great since that is the "Per-binary" panic, while we want a "per-input" panic to discover deadlocked fuzz targets.
That btw is another argument against the new hardcoded 60s, it lets cases where a deadlock is much quicker to see run for much longer.
All in all, I propose --fuzz.timeout to allow users to set this per-input timeout.
Happy to implement it
Proposal Details
The fuzz worker (
go/src/internal/fuzz/worker.go
Line 492 in 63d8363
I have a few fuzzers that sometimes time out within the 10s, so I appreciate the update to 60, but I think the clean way of doing this is not to have a hardcoded constant laying around in the code that gets updated whenever maintainers run into the same issues that users do, but to make it configureable.
There was already a proposal for
--fuzz.timeouthere: #46220 which was closed by a PR that doesn't really address the issue afaict. I agree that overloading--timeoutisn't great since that is the "Per-binary" panic, while we want a "per-input" panic to discover deadlocked fuzz targets.That btw is another argument against the new hardcoded 60s, it lets cases where a deadlock is much quicker to see run for much longer.
All in all, I propose
--fuzz.timeoutto allow users to set this per-input timeout.Happy to implement it