-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
testing: visualize fuzz corpus coverage #46765
Comments
This may be more complicated than it seemed on the surface. Since we add the libfuzzer-style counters during compilation, while doing other things to the source (like in-lining), the code we are instrumenting does not necessarily look like the source on disk, making mapping from counter positions to source positions complicated. One other approach would be to just use the existing |
IIUC the suggestion is to instrument the program with two different coverage metrics, produce a single binary where both coverage metrics are aggregated during execution, but the two different metrics are post processed differently. So go tool cover is used for producing reports and the libfuzzer style counters are used for determining if coverage increased. Is this an accurate understanding of the approach? Another approach could be to re-run the fuzzer generated tests under a |
/cc @golang/fuzzing |
It seems like this could be done with a minimal change: add a |
I just ran into wanting this.
It would be nice if it were that simple. I'd settle for some way to output the generated corpus, after a |
Apologies if this redundant, but I wanted to look at the fuzzing coverage for a project today and found this issue. I ran the following commands as a workaround to copy the fuzz cache to "testdata/fuzz" and generate a cover profile:
which seems to work today |
The above is not as convenient for workspaces. It'd be nice to add this as a subcommand and also for the fuzzer to report where the corpus is being loaded from and stored to on disk. See also great suggestions in #50432 (comment) |
It would be nice to be able to visualize the source coverage provided by an input corpus, in a similar manner to the coverage information provided for unit tests.
Fuzzing counters are implemented in a slightly different fashion to the (testing) coverage counters, but probably a similar method can be used to produce compatible coverage profiles for use with
go tool cover
.The text was updated successfully, but these errors were encountered: