Go version
go version go1.25.x linux/amd64
Output of go env in your module/workspace:
Not available at the moment. I can provide the full `go env` output later if needed.
What did you do?
What version of Go are you using?
go version go1.25.x
Does this issue reproduce with the latest release?
Yes.
What did you do?
The built-in Go fuzzer currently supports stopping after a fixed duration using -fuzztime.
In practice, during long-running fuzzing campaigns, coverage often reaches a plateau long before the configured timeout expires.
For example:
- coverage grows during the first several minutes;
- afterwards no new interesting inputs or coverage are found for tens of minutes or even hours;
- the fuzzer continues consuming CPU until
-fuzztime expires.
This is especially noticeable in CI and Kubernetes-based fuzzing infrastructure where CPU time is limited.
This is not a new fuzzing concept. AFL++ provides a similar mechanism through the AFL_EXIT_ON_TIME environment variable:
AFL_EXIT_ON_TIME causes afl-fuzz to terminate if no new paths were found within a specified period of time (in seconds). May be convenient for some types of automated jobs.
Reference:
https://aflplus.plus/docs/env_variables/#settings-for-afl-fuzz
What did you expect to see?
It would be useful to have a stopping condition based on coverage progress rather than only elapsed time.
For example:
go test -fuzz=FuzzFoo -fuzzplateau=10m
where the fuzzer exits if no new coverage has been discovered for 10 minutes.
Alternatively, exposing coverage progress or "new coverage discovered" events through an API or statistics would allow external orchestrators to implement their own stopping policy without introducing a new command-line flag.
What did you see instead?
Currently the only built-in stopping condition is elapsed time (-fuzztime), so fuzzing continues even when coverage has not changed for a long period.
What did you see happen?
The built-in Go fuzzer currently supports stopping only after a fixed duration using -fuzztime.
In practice, coverage often reaches a plateau long before the configured timeout expires. After that point, the fuzzer may continue running for tens of minutes or even hours without discovering new coverage while continuing to consume CPU resources.
This is especially noticeable in CI pipelines and Kubernetes-based fuzzing infrastructure where compute resources are limited.
A similar concept already exists in AFL++ through the AFL_EXIT_ON_TIME environment variable:
AFL_EXIT_ON_TIME causes afl-fuzz to terminate if no new paths were found within a specified period of time (in seconds). May be convenient for some types of automated jobs.
Reference:
https://aflplus.plus/docs/env_variables/#settings-for-afl-fuzz
What did you expect to see?
It would be useful to provide a way to stop fuzzing after no new coverage has been discovered for a configurable period of time.
For example:
go test -fuzz=FuzzFoo -fuzzplateau=10m
Alternatively, exposing coverage progress or notifications about newly discovered coverage would allow external tools to implement the same policy without introducing a dedicated command-line flag.
Go version
go version go1.25.x linux/amd64
Output of
go envin your module/workspace:What did you do?
What version of Go are you using?
go version go1.25.x
Does this issue reproduce with the latest release?
Yes.
What did you do?
The built-in Go fuzzer currently supports stopping after a fixed duration using
-fuzztime.In practice, during long-running fuzzing campaigns, coverage often reaches a plateau long before the configured timeout expires.
For example:
-fuzztimeexpires.This is especially noticeable in CI and Kubernetes-based fuzzing infrastructure where CPU time is limited.
This is not a new fuzzing concept. AFL++ provides a similar mechanism through the
AFL_EXIT_ON_TIMEenvironment variable:Reference:
https://aflplus.plus/docs/env_variables/#settings-for-afl-fuzz
What did you expect to see?
It would be useful to have a stopping condition based on coverage progress rather than only elapsed time.
For example:
where the fuzzer exits if no new coverage has been discovered for 10 minutes.
Alternatively, exposing coverage progress or "new coverage discovered" events through an API or statistics would allow external orchestrators to implement their own stopping policy without introducing a new command-line flag.
What did you see instead?
Currently the only built-in stopping condition is elapsed time (
-fuzztime), so fuzzing continues even when coverage has not changed for a long period.What did you see happen?
The built-in Go fuzzer currently supports stopping only after a fixed duration using
-fuzztime.In practice, coverage often reaches a plateau long before the configured timeout expires. After that point, the fuzzer may continue running for tens of minutes or even hours without discovering new coverage while continuing to consume CPU resources.
This is especially noticeable in CI pipelines and Kubernetes-based fuzzing infrastructure where compute resources are limited.
A similar concept already exists in AFL++ through the
AFL_EXIT_ON_TIMEenvironment variable:Reference:
https://aflplus.plus/docs/env_variables/#settings-for-afl-fuzz
What did you expect to see?
It would be useful to provide a way to stop fuzzing after no new coverage has been discovered for a configurable period of time.
For example:
Alternatively, exposing coverage progress or notifications about newly discovered coverage would allow external tools to implement the same policy without introducing a dedicated command-line flag.