Skip to content
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

internal/fuzz: handle I/O error writing crasher to testdata corpus #48495

Open
jayconrod opened this issue Sep 20, 2021 · 1 comment
Open

internal/fuzz: handle I/O error writing crasher to testdata corpus #48495

jayconrod opened this issue Sep 20, 2021 · 1 comment

Comments

@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Sep 20, 2021

When the fuzzing engine finds an input that causes an error in the fuzz function, it normally attempts to write that input to a file in testdata/fuzz/$target (where $target is the name of the fuzz target), relative to the package directory.

If this file can't be created, for example, because the package is part of the read-only module cache, go test -fuzz just prints the I/O error then exits. The user has no way to find out what the crashing input was.

go test -fuzz should ensure that these files are written somewhere. The fuzz cache is very likely to be writable since it's part of the build cache, so that would be a good location. go test -fuzz should print an alternative message, pointing to the newly written file. Unfortunately, it can't be used directly with go test -run.

@bcmills
Copy link
Member

@bcmills bcmills commented Sep 20, 2021

If this file can't be created, for example, because the package is part of the read-only module cache,

Given the -modcacherw flag, we should probably avoid even trying to write to modules outside of the main module or workspace — it would be really confusing to see a recurring fuzz failure that doesn't reproduce on a clean machine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants